Lockscreen

gsettings set org.mate.desktop.lockdown disable-lock-screen 'true'
gsettings set org.gnome.desktop.lockdown disable-lock-screen 'true'

proxy: ssh user@server -D 7777
proxy: socks 5 - localhost 7777


ssh -t server1 ssh server2

Export barshrc

export EDITOR="mcedit"
export TERM=xterm-256color


Terminator

Ubuntu Mono 13
export TERM=xterm-256color; sudo -s; clear;
#74B268
#33322F

mc  modarin 256
deb http://www.tataranovich.com/debian vivid main
deb-src http://www.tataranovich.com/debian vivid main

deb http://www.tataranovich.com/debian wily main
deb-src http://www.tataranovich.com/debian wily main

tmux

su user
(можно запускать несколько сессий от каждого пользователя и в каждой несколько окон)
tmux новая сессия
tmux attach подключаемся к сессии

Ctrl+b  (ключ для всех остальных действий)
     с - create (создаем новое окно в текущей сессии)
     w - windows (получаем список окон в текущей сессии и переходим на него)
     d - detach      (отключится от текущей сессии, процессы внутри будут работать)

В любом окне сессии exit - выход из нее

ssh логин на все сервера под конкретным пользователем

change .ssh/config to

Host *
    User my.login

Вернуть eth0 после клонирования vm через virt-clone

При клонировании kvm vm через virt-clone eth0 меняется  на eth1

Открываем /etc/sysconfig/network-scripts/ifcfg-eth0
убиваем HWADDR=какой-то мак

Убиваем /etc/udev/rules.d/70-persistent-net.rules

reboot
бинго!

ifconfig peth0 down  
ip link set peth0 name eth0  
ifconfig eth0 up

Оптимизируем 1с 7.7 025/027

самый простой способ включить кэширование записи для всех файлов- отключить вызов FlushFileBuffers(hFile). для этого для платформы 7.70.025 надо пропатчить файлик dbeng32.dll: ищем последовательность "50 FF 15 40 C0 11 1F", заменяем на "B8 FF FF FF FF 90 90". Теперь 1С не будет делать принудительный сброс файловых буферов на диск при каждой записи, т.е. запись на диск будет кэшироваться и сброс файловых буферов будет делаться средствами самой ОС (для NTFS каждые несколько секунд). Значительно уменьшается фрагментация файлов на диске и отпадает необходимость помещать временные файлы на RAM-диск. Этот метод дает очень хорошие результаты для локального и терминального режимов. Использовать это для сетевого режима не рекомендую, т.к. не тестил и вероятно может привести к повреждению базы.
более продвинутый способ - выборочное кэширование файлов. для этого делается перехват вызова FlushFileBuffers() с помощью ВК или подменой dll и проверяется хэндл файла- если например это временный файл или *.CDX базы, то файл кэшируется, если *.DBF базы, то происходит вызов FlushFileBuffers().

v7.x: Быстрый перенос списка баз с одного компьютера на другой

Для 7.7 :
На компьютере из которого нужно выгрузить список баз запускаем:
Код DOS Batch File
  regedit /ea 1СBase.reg HKEY_CURRENT_USER\Software\1C\1Cv7\7.7\Titles  


В результате получается reg файл 1СBase.reg со списком баз, запускаем его на другом компьютере, запускаем 1С и базы уже занесены

Для того, чтобы не обновлять Kerio Control версий 7.0.1 - 7.2.2  до версии 7.2.2 patch 4 build 3782 достаточно внести изменения в файл конфигурации winroute.cfg при остановленной службе Kerio Control. Открыв данный файл в текстовом редакторе, необходимо найти секцию:

<table name="SiteFilter">
<variable name="DiaServerUrl">url.esoft.com</variable>
<variable name="CacheEnabled">1</variable>
<variable name="MaxCacheSizeInBytes">1048576</variable>
<variable name="MinCacheSizeInBytes">524288</variable>
<variable name="CacheExpirationLimitInMins">1440</variable>
<variable name="SecretCheckTimeout">120</variable>
</table>

и изменить значение параметра DiAServerUrl следующим образом:

<variable name="DiaServerUrl">url.zvelo.com</variable>

после чего запустить службу Kerio Control и убедиться в работоспособности WebFilter и корректности ответов на запросы по категорированию сайтов.

Версия Kerio Control 7.2.2 patch 4 build 3782 выполняет принудительное изменение данного параметра без внесения изменений в файл конфигурации. Других отличий от публичной версии 7.2.2 build 3443 нет, поэтому переходить на эту версию не имеет смысла.

Изменение адреса сервера ESOFT на url.zvelo.com необходимо учесть при работе с пакетами ELUS и KEAP, изменений в код скриптов пакетов вносить не требуется.

http://itblog.su/vosstanovlenie-sysvol-reshenie-problemy-replikacii-sysvol.html

Советы по предварительной настройке программного окружения 1С 7.7

      Давайте вспомним, как работает платформа 1С 7.7 DBF. У каждого пользователя указан так называемый рабочий каталог, имя пользователя, полное имя пользователя. При старте платформа 1С проверяет, нет ли в рабочем каталоге пользователя файла *.lck (режим, когда рабочий каталог пользователя не указан – не рассматриваем, позже станет ясно - почему). Если файл lck есть – значит данный пользователь уже работает и 1С не пустит его в базу, выдав сообщение “каталог пользователя занят”. Если такого файла нет – пользователь начинает работу. При открытии пользователем экранных форм, содержащих реквизиты с сохраненными настройками, платформа 1С извлекает эти настройки из файла *.cfg, лежащего, конечно же, в рабочем каталоге пользователя. Замечу, что в данном файле со временем скапливается много мусора, причем файл может даже оказаться поврежденным. Во время работы пользователя, и соответственно, выполнения программного кода, платформа 1С выполняет некие действия, из которых нас интересует следующее: опишу на примере - когда пользователь запускает отчет, в котором выполняется запрос, состоящий, с точки зрения платформы 1С, из нескольких простых запросов – платформа 1С выполняет простые запросы по очереди, сохраняет результаты каждого простого запроса в виде файлов dbf в рабочем каталоге пользователя, после чего считывает их заново, и производит окончательное формирование результата запроса.

Правило №1:
1. Каждому пользователю должен быть назначен рабочий каталог. В этом случае настройки каждого пользователя, будут хранится в отдельном файле cfg, а не в одном файле cfg на всех пользователей. Временные файлы dbf также будут хранится в отдельных каталогах.
2. Размер файла cfg каждого пользователя не должен превышать нескольких сотен килобайт (и, тем более, не должен быть размером 1 мегабайт и более). Файл cfg размером 1 мегабайт (и больше) приводит к серьезному замедлению работы пользователя. Рекомендую безжалостно удалять cfg файл, если его размер больше чем 200-400 килобайт. Для профилактики, оптимизации, или устранения торможения 1С – удалите файлы cfg всех пользователей.
3. Тот факт, что 1С создает временные dbf файлы (не считая *.cfg, *.lck) в рабочем каталоге пользователя, определяет следующую идею оптимизации. Рабочие каталоги пользователей нужно располагать на самом быстром жестком диске сервера (нежелательно, чтобы на этом же диске была операционная система, или файл подкачки).

      В объектной модели 1С существует только два вида объектов, которые может создавать интерактивно пользователь – это элемент справочника, и документ. Для оповещения всех работающих экземпляров 1С о том, что элемент справочника (либо документ) открыт (и значит недоступен для изменения), 1С применяет тот же способ - создание временных файлов. В случае документа, в каталоге информационной базы 1С создается файл 1sjourn.$lk, в котором блокировкой определенного байта фиксируется факт открытия экранной формы объекта пользователем. Для элементов справочников создается файл sс****.$lk, где **** - внутренний идентификатор справочника в конфигурации (идентификаторы всех объектов конфигурации можно узнать, открыв любым текстовым редактором файл 1cv7.dd). Подробнее об этом методе блокировки можно прочитать тут. Мы же можем только вздохнуть, и констатировать, что механизмы платформы 1С DBF 7.7 архаичны и используют методы “вековой давности”. Впрочем, последний релиз платформы 7.7 действительно выпущен в далеком 1999 году.

Правило №2:
1. Учитывая реалии современной жизни, а именно тот факт, что жизнь современной операционной системы без антивирусной программы немыслима – проводим тонкую настройку антивируса. Никогда не используйте в настройках исключений антивируса – исключение всего каталога с информационной базой 1С. Нужно задать исключения только для файлов с масками: $lk, *.cfg, *.mlg, *.ert, *.efd, *.log, *.upd, *.md, *.dbf, *.cdx, *.xml. Все остальные файлы в каталоге базы 1С антивирус должен сканировать. Тем самым вы "убьете двух зайцев": избежите “торможения” базы 1С из-за антивируса, и не позволите вирусам спокойно плодится в укромных подкаталогах каталога информационной базы 1С.

      Знайте также, что платформа 1С 7.7 DBF, не ограничиваясь созданием временных файлов в рабочих каталогах пользователей и в каталоге базы, создает свои временные файлы и в специальном каталоге для временных файлов. Кстати, с помощью ключа командной строки \Т можно явно указать программе 1С, где ей следует создавать временные файлы. Например так: С:\1С77.ADM\1cv7.exe /TD:\ (задан каталог для временных файлов – D:)
      Полагаю, перечисление всех типов временных файлов создаваемых 1С, заставило читателя вспомнить о “старом лекарстве от всех временных файлов” – драйвере RamDrive (или аналогах)? Не рекомендую его применять по ряду причин. В первую очередь по причине неэффективности способа.
      Как же тогда ускорить работу большой базы 1С 7.7 в формате DBF? А вот как. Большинство из нас, полагаю, давно не пользовались утилитой дефрагментации диска (за ненадобностью). О вашей базе: если у вас большая база DBF, т.е. 1-10 гигабайт, то вам стоит запустить анализ фрагментации жесткого диска, на котором находится каталог с базой 1С. Если под базу 1С не выделен отдельный жесткий диск на сервере, и, соответственно, на жесткий диск часто пишутся и удаляются данные, то, в большинстве случаев, самые большие файлы базы 1С (это файлы регистра партий, регистра продаж, табличной части документа реализация и т.д.) фрагментированы на несколько тысяч частей.

Правило №3:
1. Не допускайте чрезмерной фрагментации файлов базы 1С (а большая DBF база на невыделенном жестком диске очень склонна к фрагментации). Приведу пример (совсем не редкий из практики): если у вас файлы регистра партий, регистра продаж, табличной части документа реализация фрагментированы на 3000 частей каждый, то дефрагментация диска ускорит работу вашей базы в разы. В зависимости от скорости роста фрагментации, рекомендую запускать автоматическую дефрагментацию раз в сутки (или раз в неделю). Для автоматической дефрагментации используйте запуск утилиты defrag.exe с параметром – именем жесткого диска. Например: defrag.exe D:

      Выполнив эти мелкие, но полезные шаги по оптимизации, предпримем более серьезные действия. Начну издалека. Как известно, DBF база состоит из совокупности dbf и cdx файлов (прочие файлы служебного назначения в расчет не берем). Таких файлов обычно несколько тысяч. Совокупный размер этих файлов может достигать нескольких гигабайт. Попробуем оценить следующее - какой объем информации 1С нужно считать из файлов, расположенных на жестком диске, при простом действии - проведении документа РеализацияТМЦ? Например, в базе, с которой я сейчас работаю (речь идет о конфигурации Торговля и Склад 7.7), размер файла итогов регистра ОстаткиТМЦ - 30 мегабайт, размер файла итогов регистра ПартииНаличие - 60 мегабайт. Как мы знаем, при проведении документа реализация в коде модуля проведения анализируются итоги регистра ОстаткиТМЦ и ПартииНаличие. Значит, платформе 1С для анализа итогов этих регистров придется прочитать оба этих файла с диска, т.е. считать информацию размеров 90 мегабайт. Не будем забывать, что система 1С также должна будет считать с диска файл журнала документов, и многие другие файлы. Операции чтения с диска занимают некое время, и скорее всего, в случае большой базы - немалое. Поэтому, уделим пристальное внимание тонкой настройке серверной операционной системы в части её работы с жестким диском. Провести настройку нам поможет утилита тонкой настройки операционной системы сервера - ConfigNT.

Правило №4:
1. В оснастке администрирования сервера отключаем службу индексирования диска, если она у вас включена.
2. В оснастке администрирования отключаем службу теневого копирования тома.

Запускаем утилиту ConfigNT и выполняем следующие действия:

3. На закладке Logon устанавливаем галку в чекбоксе "AutoEndTasks". Установка данной опции сообщит операционной системе сервера о том, зависшие процессы необходимо завершать немедленно, не оповещая об этом пользователя.
4. Установливаем на закладке Memory Management галку в чекбоксе "Maximize Throughput for File Sharing". Тем самым мы дадим знать операционной системе сервера, что желаем, чтобы для использования файлов выделялся максимально доступный объем памяти. При данной настройке, операционная система не будет сбрасывать долго не используемые страницы оперативной памяти на диск, т.е. в виртуальную память.
5. Устанавливаем на той же закладке галку в чекбоксе "Use large system cache". Установка данной опции сообщит операционной системе сервера о том, что под кэширование дисков нужно выделить максимум оперативной памяти.
6. На закладке Other снимаем галку в чекбоксе "Update last access time on NTFS". Установка данной опции сообщит операционной системе сервера о том, что не следует обновлять время последнего доступа к файлам.

Также рекомендую в разделе реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Filesystem создать ключ NtfsDisable8dot3NameCreation с типом DWORD и значением равным 1. По умолчанию, файловая система NTFS создает и хранит таблицу всех имен файлов и папок на диске в формате MS-DOS (т.е. 8 символов для имени файла, и 3 символа для расширения). Это нужно для совместимости со старыми приложениями. Установкой значения 1 для параметра NtfsDisable8dot3NameCreation отключим эту особенность NTFS.

Для того чтобы параметры возымели действие - перезагрузите сервер.

      И, последний совет - если конфигурация вашего сервера позволяет использовать SSD жесткий диск - очень желательно приобрести жесткий диск такого типа. Жесткие диски использующие технологию SSD, обеспечивают на порядок большую скорость чтения информации с жесткого диска, нежели у жестких дисков традиционного типа, что увеличивает скорость работы базы 1С 7.7 в формате DBF в разы. Подробней о технологии SSD можно почитать тут.

Советы по оптимизации конфигурации 1С 7.7 DBF

      Самый простой и самый эффективный способ оптимизировать быстродействие конфигурации 1С - выполнить так называемую "свертку", или "обрезание" базы. Но, не всегда эта операция допустима, и возможна. Продолжая повествование, будем исходить из того, что свертка конфигурации нежелательна.

      Рассмотрим работу платформы 1С 7.7 “изнутри”. Основными объектами для хранения информации о хозяйственных операциях в 1С являются справочники и документы, как мы уже выяснили. В принципе, оперируя лишь этими объектами, мы могли бы получить все необходимые нам данные. Но, разработчики программы 1С ввели в объектную модель дополнительные объекты, призванные агрегировать информацию (из справочников и документов) и предоставить возможность быстрого доступа к ней. Такие объекты – это регистры остатков, регистры оборотов и проводки. Указанные объекты обычно хранят информацию (причем учитывая хронологию событий во времени) о движении остатков товаров, денежных средств и т.п.

Неправильное проектирование регистров зачастую приводит к ощутимому торможению базы 1С.

Правило №1:
1. Не используйте галки “Отбор движений” и “Отбор итогов” для измерений регистра без крайней необходимости, так как это увеличивает размер индекса. Крайняя необходимость – тот случай, когда в программном коде необходимо использовать функции ВыбратьДвижения(), ВыбратьИтоги() с фильтром по искомому измерению.
3. При проектировании регистра учитывайте особенность платформы 1С 7.7. Дело в том, что платформа создает один составной индекс для всех измерений регистра. Поэтому, полезный совет – располагайте измерения в регистре в порядке убывания частоты использования измерения в отборах. Например для регистра ОстаткиТМЦ правильным будет порядок следования измерений: а)Номенклатура б)Склад в)Фирма г)ЦенаПрод. А вот такой порядок: а)Фирма б)Склад в)Номенклатура г)ЦенаПрод – приведет падению скорости выборки данных из регистра и увеличению размера индексного файла.
4. Не допускайте случаев “не закрывающихся” регистров.

      Еще одно узкое место платформы 1С 7.7 – это константы. С точки зрения методологии 1С, константы предназначены для хранения часто используемой, но редко изменяющейся информации (поэтому, наверное, разработчики 1С сочли возможным объединение всех констант в одну таблицу). На практике же, программистами часто допускается ситуация, когда в константы часто пишется некая информация. Такая методика приводит к печальным последствиям.

      Немного информации о блокировках, применяемых платформой 1С 7.7 DBF. Блокировки бывают “на чтение” и “на запись”. Я специально выбрал эти термины, т.к. уже по названию блокировки понятно, как платформа 1С выбирает, которую применить. Сейчас нас интересует лишь возможность одновременной установки блокировок. Итак, блокировка “на запись” исключает установку другой блокировки “на запись”, а также “на чтение”. Блокировка “на чтение” разрешает установку других блокировок “на чтение”, но запрещает установку блокировок “на запись”. Отсюда следует простой вывод – если в константу часто идет запись, то, часто возникающие блокировки "на запись" будут исключать установку блокировок обоих типов, что в высоконагруженной системе (40-70 пользователей), приведет к появлению сообщений о ошибке транзакции у пользователей программы. В случае же использования констант “по назначению”, т.е. когда значения из констант будут большей частью считываться – ошибок транзакций не возникнет, т.к. блокировки “на чтение” могут устанавливаться одновременно несколькими экземплярами 1С.

Правило №2:
1. Используйте константы по назначению. Недопустима, например, ситуация, когда при проведении каждого документа в некую константу записывается информация.

      Таблица констант, к сожалению, не единственное “узкое” место в структуре таблиц, применяемых платформой 1С 7.7 для хранения данных. Еще одно узкое место – таблица документов. При сохранении или проведении документа, 1С блокирует данную таблицу для всех пользователей, кроме того, кто выполняет сохранение (проведение). В высоконагруженной системе блокировки таблицы документов будут неизбежно (и часто) вызывать ошибки транзакций у пользователей. Более того, лавина транзакций будет вызывать растущую загрузку процессора – вплоть до 100%.

Правило №3:
1. Установите данную разработку. Разработка позволяет снизить загрузку процессора во время ожидания блокировки таблицы до незаметных величин. Более того, за счет нехитрого, но эффективного алгоритма повторных попыток заблокировать таблицу, количество неудачных попыток заблокировать таблицу снизится, а значит, заметно уменьшиться количество транзакций.

Примечание: для платформы 1C 7.7 SQL существует более эффективный инструмент – “гибкие блокировки”, но в данной статье платформа 1C 7.7 SQL рассматриваться не будет.

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

Для этого можно применить, например, такие способы:
1. Для применения способа необходима установленная компонента УРБД. Создаем новую периферийную базу. Пользователей делим на 2 группы: а) пользователи, создающие документы текущей датой б) пользователи, формирующие отчеты, и создающие документы как текущей датой, так и "задним числом". Пользователи группы "а" работают в прежней базе. Пользователи группы "б" работают в периферийной базе. Для синхронизации данных между базами настраиваем автообмен.
2. Этот способ условно можно назвать - дублирование регистров. Суть способа состоит в том что в конфигурации заводятся новые регистры - дубли существующих. Выбирается день Х. На начало дня Х делается "снимок" итогов регистров остатков и заносится в соответствующие им дубли. В код конфигурации вносятся такие изменения, что все документы, начиная со дня Х проводятся по новым регистрам, программный код отчетов тоже изменяется - для отчетов по регистрам оборотов в код запросов просто дописывается второй регистр. Отчеты по регистрам остатков переписываются так, что до дня Х отчет формируется по старому регистру, со дня Х - по свежесозданному дублю этого регистра. Недостаток: Сформировать отчет с начальной даты = (ДеньХ-1 день) по конечную дату (ДеньХ+1) конечно же, нельзя.

      На нескольких больших базах, пребывавших под моим наблюдением, был замечен следующий эффект: при выполнении обработкой массовой записи и проведения документов одинаковым временем, скажем - 08:00:00, при возникновении ошибки транзакции документ бесследно исчезал. Полагаю, читатель знаком с утверждением, что в 1С 7.7 (как впрочем и 1С 8) в пределах одной секунды можно записать достаточно большое число документов (1000-5000 например). Вышесказанное заставляет меня в этом усомниться (по крайней мере в случае большой базы формата DBF).

      Думаю, читатель знаком и с утверждением, что позиция документа – это некая величина, зависящая от времени документа, и от порядка ввода документов в пределах одной секунды. Мои наблюдения на больших базах не подтверждают это утверждение. Типовой отчет “Остатки ТМЦ” (с детализацией по документам) выводит такие документы (имеющие одинаковое время, распределенные в пределах одной секунды) в порядке, отличающемся от порядка в журнале документов! Более того, путем определенных экспериментов было установлено, что при расчете остатков в модуле проведения такого документа, остатки выдавались неверные (в силу неверного определения позиции)!

Правило №4:
1. Т.к. вы работаете с информационной базой DBF, приближающейся к предельному объему, не искушайте судьбу – не используйте в ваших обработках массовую запись и проведение документов одинаковым временем. Документы должны записываться с шагом в 1 секунду.
2. Рекомендую иногда проверять размеры файлов 1sjourn.dbf и 1sjourn.cdx (журнал документов). В норме размер файла 1sjourn.cdx должен быть примерно в 1,5 раза больше размера файла 1sjourn.dbf. Если у вас соотношение размеров этих файлов кардинально другое (например файл 1sjourn.cdx меньше файла 1sjourn.dbf - чего быть никак не может) – то это один из признаков неисправности журнала документов.
3. Приблизительно такое же соотношение должно быть у размеров файлов 1scrdoc.dbf и 1scrdoc.cdx (перекрестные ссылки документов).

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

ГЛАВНАЯ ПРОБЛЕМА БОЛЬШИХ БАЗ 1С 7.7 DBF:

      Суть проблемы заключается в том, что в один прекрасный момент вы столкнетесь с эффектом исчезновения документов, самопроизвольным снятием документов с проведения, некорректными данными в отчетах, внезапными вылетами программы 1С с сообщением об ошибке.
      Почему так происходит? Оказывается, для файлов формата dbf, в которых платформа 1С 7.7 DBF хранит информацию, существует ограничение на максимальный размер. Для файлов формата dbf это ограничение равно 2 гигабайта. Но dbf файлов, используемых платформой 1С 7.7 максимальный размер равен 1 гигабайт. Почитать о природе данного ограничения вы можете тут.

Правило №5:
1) Заблаговременно (до достижения самым большим файлом dbf размера в 1 гигабайт) установите данную разработку.
2) После установки разработки, удалите все индексные файлы в каталоге вашей базы 1С, и запустите 1С в монопольном режиме. Индексные файлы будут воссозданы заново.

      Путем выполнения указанных в статье рекомендаций можно “вернуть форму” базе 1С 7.7 DBF даже большого размера (10-12 гигабайт), и получить с приемлемую скорость работы, с минимумом транзакций.

Надеюсь что из данной статьи смогли почерпнуть максимум информации все три категории читателей:
1) ИТ-специалисты, поддерживающие базы на платформе 1С 7.7 DBF.
2) ИТ-специалисты, которые хотят понять все недостатки платформы 1С 7.7, для аргументированного принятия решения о переходе на платформу 1С 8.2.
3) Все те читатели, кому хочется знать существующие техники оптимизации и ускорения платформы 1С 7.7 DBF.

Примечание:
      Вдумчивый читатель, разумеется, заметил некий перекос в изложении способов оптимизации. Действительно, тщательная подготовка и оптимизация программного окружения описана гораздо подробней, чем способы оптимизации непосредственно конфигурации 1С. Такое положение дел объясняется опытом автора в эксплуатации и оптимизации баз 1С 7.7 DBF. Практика показывает, что главная причина возникающего с ростом размера базы "торможения", "зависаний", увеличивающейся длины транзакции, и, соответственно - ошибок транзакций - это то, что с ростом размера базы значительно увеличивается время, требующееся 1С для извлечения информации из нескольки тысяч dbf и cdx файлов хаотично разбросанных по жесткому диску, причем, значительно фрагментированных. Во многих случаях достаточно приобрести SSD жесткий диск, и получить ускорение работы конфигурации в разы. Тогда как можно пойти другим путем - последовательно применить несколько трудоемких техник по оптимизации самой конфигурации 1С и получить ускорение всего в 30%-50%.

grep, ifconfig, man. ls in win

/sbin/iptables -t filter -A INPUT -j LOG --log-prefix "La-la-la: "
смотреть в /var/log/firewall


echo findstr %1 %2 %3 %4 %5 > %systemroot%\grep.cmd
теперь можно не задумываясь грепать вывод:

C:\WINDOWS>netstat -an | grep LISTEN

C:\WINDOWS>findstr LISTEN
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1963 0.0.0.0:0 LISTENING
TCP 10.198.17.58:139 0.0.0.0:0 LISTENING
TCP 127.0.0.1:1025 0.0.0.0:0 LISTENING
TCP 127.0.0.1:9050 0.0.0.0:0 LISTENING
TCP 127.0.0.1:9051 0.0.0.0:0 LISTENING
TCP 192.168.56.1:139 0.0.0.0:0 LISTENING

Ну и на закуску:

ifconfig:

echo IF "%1"=="-a" (ipconfig /all) ELSE (ipconfig %1) > %systemroot%\ifconfig.cmd

man:

echo %1 /?> %systemroot%\man.cmd

ls:

echo IF "%1"=="-a" (dir) ELSE (IF "%1"=="-al" (dir) ELSE (dir %1 %2 %3 %4 %5)) > %systemroot%\ls.cmd

win7 usb download tool

diskpart
list disk
select disk #
clean
create partition primary
select partition 1
active
format quick fs=fat32
assign
exit

iptables log

/sbin/iptables -t filter -A INPUT -j LOG --log-prefix "La-la-la: "
смотреть в /var/log/firewall

вот такие таблицы (напр. -t filter) и цепочки (напр. -A INPUT) 
есть по-умолчанию:

               ([ NET ])
                   |
           (mangle)(PREROUTING)
                   |
            (nat)(PREROUTING)
                   |
                  /-\
          ---<<---   --->>---
         /                   \
 (mangle)(INPUT)     (mangle)(FORWARD)
        |                    |
 (filter)(INPUT)     (filter)(FORWARD)
        |                    |
 [ local process ]           |
        |                    |
 (mangle)(OUTPUT)            |
        |                    |
 (nat)(OUTPUT)               |
        |                    |
 (filter)(OUTPUT)            |
        |                    |
         \--->>---   ---<<---/
                  \-/
                   |
           (mangle)(POSTROUTING)
                   |
            (nat)(POSTROUTING)
                   |
               ([ NET ])

разрешаем маршрутизацию
echo 1 > /proc/sys/net/ipv4/ip_forward

поднимаем перекидывание пакетов на интерфейс ppp0 (маскарадинг
удобен если адрес поднимаемый динамический, но требует больше
ресурсов):

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

или, если айпишник статический, то вот куча примеров:

iptables -t nat -A POSTROUTING -s ip_которые_ты_хочешь_спрятать_за_nat -o $INET_IFACE -j SNAT --to-source $INET_IP

iptables -A POSTROUTING -t nat -o eth0 -j SNAT --to-source 192.168.128.41

iptables -t nat -A POSTROUTING -s x.x.x.x/YY -d $WEB_SERVER -p tcp --dport 80 -j SNAT --to-source $INET_IP


вот эти наверно пригодятся:

iptables -t nat -A PREROUTING -p tcp -d 192.168.0.20 --dport 800 -j DNAT --to-destination 192.168.1.1:443

iptables -t nat -A POSTROUTING -p tcp -s 192.168.0.0/24 -d 192.168.1.1 --dport 443 -j SNAT --to-source 192.168.1.2 

забираем почту

#set syslog

defaults       protocol pop3,
               timeout 60,
               nokeep,
               fetchall,
               mda "procmail -d %T"

poll "ip_adress",
    user "user@user.ua",
    password "password";

работа postfix.

Попасть почта в postfix может 4-мя способами:
1. Локально, через оболочку sendmail: sendmail вызывает утилиту postdrop,
которая складывает письмо в папку maildrop
2. Через SMTP соединение - от демона smtpd
3. После преобразования уже полученного письма через файлы alias'ов, письмо
вновь попадает в postfix
4. Внутренние сообщения, defer и bounce.

После того, как почта попала в Postfix, она попадает к демону cleanup (напрямую
от smtpd или же через утилиту pickup, которая извелкает почту из директории
maildrop, которая туда попала от демона postdrop). Cleanup исправляет заголовки
почтового письма, приводя его к стандарту, сотрудничая с trivial-rewrite. И уже
готовенькое письмецо складывает в папку incoming, попутно сообщая
query-менеджеру о новом поступлении.

Query-менеджер (qmqr) распределят письмо по агентам доставки, также, как и
cleanup, сотрудничая с trivial-rewrite.

Доставка осуществляется через агенты:
1. Локальному пользователю, у которого есть shell доступ - через агента local.
Домены, для которых POstfix будут осуществлять локальную доставку, перечислены в
mydestination. Для них просматривается файл алиасов и .forward.
2. Virtual alias - это чисто виртуальные пользователи, просто происходит
преобразование почтового адреса. Для них не смотрится ни файла алиасов, ни тем
более .forward. Перечислены в virtual_alias_domains и virtual_alias_maps.
3. Virtual mailbox - по-моему, самый полезный, позволяет принимать почту для
пользователей без shell-доступа. Перечислены в файле virtual_mailbox_domains и
virtual_mailbox_maps
4. Relay. Это когда почта отправляет другому MTA. Испльзуется как вторая MX
запись. Описаны в relay_domains.
Почта для перечисленных выше случаев доставляется от ЛЮБОГО почтового агента
безо всякой аутентификации. Если же почтовое письмо не доставляется по
указанному адресу, это означает только одно - через Postfix посылают почту
левому MTA, и в таком случае:
5. Почта отправляется через агента smtp, перед этим пользователь обязан пройти
аутентификацию, иначе наш почтовик превратится в Open-Relay.

Сконфигурировать можно и другим агенты, для этого идем в файл master.cf и его
правим.

Запуск: postfix start - запускает главного демона master, который уже запускает
все остальные демоны.
Postfix reload - после внесения изменений, но перед этим надо сделать
postfix check - проверить синтаксис
newaliases - создать базу из текстового файла. Осталось в наследство от
sendmail. Путь к файлу указан в alias_database (alias_maps кроме текстового
файла может содержать, например, nis, этим они и отличаются).
postconf - посмотреть текущие настройки, возможны опции
-e изменить настройки
-d посмотреть настройки по-умолчанию
-m посмотреть доступные типы lookup-database
postmap - создать lookup-database, полезные опции
-q посмотреть значение по ключу
postalias - специально для создания файла алиасов, аналог newaliases

Формат файла aliases

local_part: local_part | /path/to/file | \| /path/to/progrma |
:include:/path/to/file

Не всегда можно направить почту в файл или программу: используйте
allow_mail_to_files и allow_mail_to_commands, допустимые аргументы: alias,
forward, include

Доставка по локальным адресам осуществляется с привилегиями, которые установлены
у файла aliases, за исключением пользователя root, для него доставка всегда с
привилегиями default_priv, то есть по-умолчанию с никакими. Вывод, всегда
перенаправляйте почту от root :)

И не забудьте направить alias_maps и alias_database на файл с алиасами.


Всегда нужно править:
$myhostname - имя хоста
$mydomain - имя домена
$myorigin - логично указывать = $mydomain, добавляется ко всей почте, которая
идет с локального хоста, например, юзвер rodriges шлет почту командой mail
j_p_montoya@mail.ru, в таком случае поле From будет rodriges@$myorigin. Также
добавлется по-умолчанию к принятой почте без домена.
$mydestination - как сказано выше, для всех доменов доставка осуществляется
локально. Есть смысл указать = $mydomain, тогда почтовик будет принимать почту
для всего домена.
$mynetworks - с этих сетей можно отправлять почту куда угодно, другими словами,
предоставлять услугу relay

Также следует ужесточить требование к демону smtpd - ведь через него чаще всего
поступают письма, следовательно, нужно быть готовым к DOS.
smtpd_recipient_limit - сколько может быть адресатов у одного письма, то есть
кол-во записей RCPT: по-умолчанию 1000, что явно много
message_size_limit - макс. размер письма, принятого не только по smptd, но и
локально.

Если клиент, подключенный к smptd ведет себя неправильно, вступают в силу
smtpd_soft_error_limit - число нарушенний, после него интервал ответу
увеличивается на
smtpd_error_sleep_time, а по достижению кол-ва ошибок
smtpd_hard_error_limit происходит disconnect

Рано, но все же напишу.

canonical_maps = hash:/ Пусть к файлу, где ожидается

user@domain.tld other
user other
@domain. tld other

Этот файл обрабатыватся самым первым при приеме или отправке письма и
переписывает и заголовки и конверт. Можно ограничить его действие

sender_canonical_maps и recipient_canonical_maps, только при отправке или
приеме. Меняются полностью все совпадения.

Елси домен или пользователь уже не живут у нас, но какое-то время нужно
поддерживать приемственность, заполняем
relocated_maps = hash:///, формат тот же, что и в recipient_maps, если на этот
адрес приходит письмо, postfix в ответ шлет bounce с указанием, что адрес больше
не поддерживается и новым адресом. Причем здесь может быть указано любое имя в
домене, даже тот аккаунт, которого никогда не было

Query-Manager (qmqr)
Содержит свои очереди:
1. Incoming - необработанные новые письма
2. Active - письма в обработке
3. Deferred
4. Bounced
5. Corrupted - незнаю, говорят, здесь могут появляться письма, что
свидетельствует о проблемах

Если есть временые проблемы, письмо идет в deferred, если Postifix получает
отлуп от сервера, письмо идет с ошибкой идет обратно отправителю, при этом
возвращается не все письмо, а лишь
bounce_size_limit байт, которое по умолчанию равно 50000.

Если же письмо идет в deferred, оно помечается временем, когда стоит вновь его
отправить. Каждая неудачная попытка увеличивает время следующей отправки (в
диапазоне minimal_backoff_time...maximum_backkoff_time), пока время не достигнет
maximum_query_lifetime, после чего отправителю возвращается письмо, что доставка
невозможно.

Очередь deferred сканируется каждые query_run_delay секунд, по умолчанию 1000.

Интересная особенность qmqr - он никогда не ломится понапрасну, то есть если от
сервера нет ответа, он замораживает все попытки. Когда же сервер начинает
отвечать, сначала из очереди извлекаются не более
initial_destination_concurrency писем, которые доставляются одновременно, и если
все проходит нормально, число параллельных доставок через всех агентов плавно
увеличивается до значения default_destination_concurrency_limit. Если же
требуется для разных агентов разное значение параллельно доставляемых писем
изменяеми AGENT_destination_concurrency_limit, где AGENT - имя агента, напримерм
smtp, local, virtual.

И, наконец, контроль. Postfix может отсылать письма на аккауте postmaster при
событиях, которые указаны в
notify_classes bounce 2bounce delay policy(это если нарвался на анти-спам)
protocol resource software.
Вообщем письма шлются на адреса, которые можно задавать, но это уже лишнее
error_notice_recipient
delay_notice_recipient
bounce_notice_recipient
2bounce_notice_recipient
Так, написал для галочки.

Естественно, очередь можно смотреть и направлять в нужное русло :)
mailq - посмотреть содержимое очереди
postqueue -p - то же самое.
Если письмо в активной очереди, оно помечено '*', в очереди hold - '!', в
deferred - ничем не помечено, их то и видим чаще всего.
postqueue -f - сразу же отправить все письма
postquere -s domain - сразу же отправить почту для данного домена, но, чтобы это
работало, нужно указать домен в
fast_flush_domains, по умолчанию там только $relay_domains

Смотрим письмо командой
postcat -q ID, и, если письмо не нравиться, удаляем его
postuser -d ID, где ID смотрим postqueue -p, или же командой
postuser -ALL, удаляем ВСЕ письма
postuser -h ID, postuser -H ID - поместить / убрать письмо из очереди HOLD.
postuser -r ALL - заново письмо заочередить??????

С центральной осью разобрались.


Local Delivery

Есть 2 типа ящиков - mailbox и Maildir. mailbox использовать не надо, для него
есть параметр
mail_spool_directory, который указывает на директорию, где будет хранится
почта.
Внутри этой директории по имени локального пользователя создается один
файл, куда и будт бросаться вся почта.
home_mailbox - это путь внути домашнего каталога, где будет почта храниться,
если на коце есть /, например MailDir/. то почта будет в Maildir формате, если
нет - в mailbox.

Все пользователи, для которых почта доставляется локально, перечислены в
local_recipient_maps, который по-умолчанию ссылается на файл с паролями и
$alias_maps. то бишь алиасы. Если пользователя нет в local_recipient_maps.
почта
отвергается.

если имя принимателя раскрывается алиасом, почта снова попадает в postfix. Если
указана
forward_path. то перед доставкой просматривается содержимое файла, и также
здесь
возможно перенаправление письма. Формат файла .forward такой-же, как и правая
часть файла aliases (т.е. name@tld,ru : name : /file : :include:/file : | path
to command. доставка в файл или команду осуществляется с правами, которые
установлены у файла .forward. за исключением, если файлом владеет root - тогда
доставка с правами default_priv.

Локальная доставка осуществляется агентом
local по доменам, указанных в mydestination. Имена пользователей в этом случае
совпадают, например, a.com & b.com, почта на root@a.com & root@b.com попадут в
один ящик.

LMTP - Local Mail Transport Protocol.

Интересная особенность. Например, если применяется pop/imap сервер, который
хранит письма не в формате mailbox/maildir. Для того, чтобы postfix доставила
письма в нестандартный ящик, применяется протокол lmtp - сервер pop/imap
принимает по lmtp письма от postfix и складывает их в свой формат. Используется
3 параметра

mailbox_transport - вначале письмо попадает агенту local. который раскрывает
alias & .forward и уже после этого передает указанному доставщику, который
должен быть прописан в файле master.cf
local_transport - то же, что и mailbox_transport, только без передачи письма
local, т.е. без раскрытия alias & .forward
fallback_transport - почта попадает к local. и если есть локальный пользователь
доставляется локально, если его нет - то применяется указанный транспорт.

Virtual delivery

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

virtual_alias_domains - указать домены
virtual_alias_maps - указать пользователей, при этом почта доставляется
локальным пользователям с shell-доступом.

В этом случае почту все равно разносит агент local


Чисто виртуальный вариант, когда у пользователей нет shell доступа, и почту
можно забрать только по pop/imap

virtual_mailbox_domains
virtual_mailbox_maps - путь к файлу, где
info@domain.tld domain.tld/info
test@dom.tld test.tld/test/

при этом доставка осуществляется агентом virtual. который не читает ни файл
alias не файл .forward

virtual_mailbox_base - относительно этой директории находятся каталоги, куда
складывается почта. Внимание, нужно создать каталог по названию домена внутри
virtual_mailbox_base
и дать на него те, права, что указаны в virtual_uid_maps/virtual_gid_maps,
ничего более внутри
делать не надо, Postfix все сам разрулит

virtual_uid_maps
virtual_gid_maps - либо static:. либо путь к файлу, где
info@domain.tld 4000
test@dom.tld 4001

Как уже сказано, агент virtual не читает файлы алиасов, но все же сделать алиас
можно, имхо, это трюк
такой. Для этого нужно указать в
virtual_alias_maps
alias@domain resolver@domain
Работает, опять же имхо, это так: Агент local читает virtual_alias_maps, и вновь
создает письмо в Postfix, где оно уже доставляется агентом virtual. В общем,
хитро :)

И напоследок снова о LMTP, здесь все тоже самое

virtual_mailbox_domains,
virtual_mailbox_maps
virtual_transport = lmtp :)

почта принимается для доменов virtual_mailbox_domains, пользователи перечислены
в virtual_mailbox_maps и вместо транспорта virtual применяется агент lmtp


Mail Relaying

Елси postfix указан не как основной MX, то все, что нужно - это добавить нужные
домены в relay_domains, тогда в случае выхода из строя основного MX почта будет
приниматься postfix и храниться в нем до тех пор, пока не поднимется основной MX
или же не наступи maximum_query_lifetime - максимальное время хранения письма в
очереди.

Все почтовый ящики указаны в
relay_recipient_maps
user1@domain any_record
user2@domain any_record
@domain.ru any_record

Если основная MX поднялась и нужно сразу доставить почту, postquery -s domain,
при этом domain должен быть указан в fast_flush_domains. Для быстрой доставки
используется демон flush, который нужные письма в нужном месте.

Если такая
transport_maps
mail@domain transport:host:port
domain transport:host:port
, которая явно определяет, что и куда нужно доставить, переписывая действие по
умолчанию, в таблице ключ может быть весь домен или один e-mail, справа должно
быть название транспорта, хост и порт. Если с хост указано доменное имя,
производится сначала DNS запрос MX и, в случае неудачи, запрос A. Если нужно
сразу A - указываеть доменное имя в квадратных скобках. Если не доменное имя, а
IP - тоже в квадратных скобках. Если не указан порт - по-умолчанию доставляется
на 25 порт. Есть специальный транспорт error, он отвергает любую почту с
ошибкой, которая указана за ним.

Если почта должна быть доставлена почтовым серверам, которые только иногда
выходят в коннект, можно использовать defer_transports, но об этом в другой раз
:)

Inbound Mail Gateway - Это когда в сети есть один сервер, смотрящий в интернет и
несколько других серверов, не смотрящих туда :) Соответственно, на Gateway все
домены, расположенные на внутренних серверах указываются в relay_domains, можно
еще добавить relay_domains_maps, и в транспортной таблице делаются записи

domain1 relay:[mail.local1]
domain2 relay:[mail.local2]

Соответственно, этим несчастным внутренним серверам нужно посылать почту на
Oubound Gateway, для чего на них прописысаются
relay_host=gateway,
а на gateway разрешают этим самым несчастным пользоваться relays, добавляя IP в
mynetworks

Spam Detection

backscatter - несчастное лицо, которому шлются bounce.
false-positive - ложное определение легитивного письма как СПАМ


Определение Спама на уровне коннекта к демону smtpd

smtpd_client_restriction - Это правило работает сразу же после подключения
клиента к серверу, до того, как сервер выдаст приветственное сообщение
smtpd_helo_restriction - проверяется домен helo
smtpd_sender_restriction - проверяет адрес/домен отправитеся
smtpd_recipient_restriction - проверяет адрес/домен получателя
smtpd_data_restriction - проверяет ээээ ?????
header_checks - проверка заголовков
body_checks - проверка тела письма

Обычно postfix не посылает клиента до момента rcpt to, даже если проверка
сработала на helo. Если это надо поменять,
smtpd_delay_reject = no

Есть такой
soft_bounce, который вместо кодов 5хх возвращает 4хх, его можно (?) использовать
для тестирования новых правил. А вот полезная фича
warn_if_reject - надо поставить это перед каждым правилом, тогда вместо
срабатывания reject, почта проходит дальше, но в логах остается запись.

А вот и они, наши герои - правила, их можно указывать в любом из smtpd_*
параметров

I. Проверка клиента.

check_client_access
check_helo_access - все они указывают на lookup таблицы, где возможны слева:
123.123.234.245 - IP адрес
domain.ru - домен
123.23 - подсеть

check_sender_access
check_recipient_access - все они указывают на lookup таблицы, где возможны
слева:
mail@mail.ru - полный адрес
mail@ - адрес для всех доменов
mail.ru - все адреса для одного домена

Справа в этих четырёх правилах может стоять следующее:

OK - почта принимается
reject текст - почта bounce вместе с опциональным текстом
discard текс - для отправителя почта считается доставленной, но на деле она
убивается
DUNNO - пропустить это правило
HOLD - положить письмо в очередь hold
FILTER transport:host - письмо отправляется в фильтр ???
4xx текст
5хх текст - письмо reject вместе с кодом ошибки

permit_auth_destination - возвращает OK, если получатель находится в
$mydestination, $virutal_alias_domains, $virtual_mailbox_domains,
$inet_interfaces, $relay_domains. Если нет,
возвращает DUNNO, а не REJECT

reject_unauth_destination - обратное к pertim_auth_destination

permit_mynetworks - если адрес отправителя находится в $mynetworks

permit_sasl_authenticated - разрешить доступ пользователям, прошедшим
SASL-аутентификацию
reject_sender_login_mismatch - это тоже относится к SASL - когда пользователю,
прошедшему
аутентификацию, разрешено в MAIL FROM: указывать только конкретный адрес, чтобы
избежать подделок,
и пользователь нарушает это правило.

II. Проверка синтаксиса.

reject_invalid_hostname - если имя хоста после HELO не является корректным,
вернуть REJECT
reject_non_fqdn_hostname - если имя хоста после HELO не является FQDN, вернуть
REJECT
reject_non_fqdn_sender
reject_non_fqdn_recipient - аналогично
smtpd_helo_required - требовать, чтобы клиент представился
strict_rfc821_envelopes - требовать, чтобы письмо удовлетворяло всем
требованиям.

III. DNS проверки
жесткие, но их нужно включать

reject_unknown_client - проверят PTR по IP клиента и проверяет, чтобы обратка
совпала с прямым именем. Замечательное правило.
reject_unknown_hostname - проверяет, есть ли A или MX записи у домена,
указанного в HELO
reject_unknown_recipient_domain
reject_unknown_sender_domain - тоже самое

IV. BlackLists

??????

Content-checking

header_checks
body_checks - regexp:/path/to/file

слева стоит регулярное выражение, справа
OK
REJECT message
DISCARD message
HOLD
FILTER transport:nexthop
IGNORE - просто удалить строчку из заголовков/тела
WARN message - сделать запись в логах, и пропустить

Важно. Чтобы не загружать процессор, проверки проводятся:
line_length_limit - только если строка имеет размер меньше указанного
body_checks_size_limit - только столько байт в теле проверяется
header_size_limit - только столько байт проверяется в заголовках

Restriction classes

Restriction classes создают правила, которые можно использовать в _правой_ части
lookup таблиц доcтупа.

Вначале мы создаем произвольные классы, перечисляя их в
smtpd_restriction_classes = uno, dos, tres

после мы определяем для каждого класса правила (как для команды smtpd_*)

uno = reject_unauth_destination, permit_mynetworks

После чего можем их использовать в любой таблице доступа

mail@mail.ru uno
ttest@mail.ru dos

Например, укажем этот файл в check_recipient_access.
Немного примеров

1.
smtpd_restriction_classes = accessive, den
smtpd_recipient_restricions = check_recipient_restriction =
hash:/etc/postfix/res
accessive = permit_mynetworks, reject
den = deny

/etc/postfix/res
test1@salsero.spb.ru accessive
test2@salsero.spb.ru den

теперь письма на test1@salsero.spb.ru могут посылать только клиенты из
$mynetworks. Более общий случай:
smtpd_restriction_classes = accessive, den
smtpd_recipient_restricions = check_recipient_restriction hash:/etc/postfix/res
accessive = check_sender_restriction hash:/etc/postfix/sen, reject
den = deny

/etc/postfix/res
test1@salsero.spb.ru accessive
test2@salsero.spb.ru den

/etc/postfix/sen
test@hotmail.ru accept
test@mail.ru reject
Теперь на test1@salsero.spb.ru можно слать только с адреса test@hotmail.ru и
точка


Ну вот, еще одна глава пройдена :).

SASL

Нужно вначале определить SASL machanisms, также известные как credentials (какие
методы аутентификации поддерживает SASL) и SASL frameworks (каким образом SASL
хранит пароли)

Sasl mechanisms
plain - логит/пассворт без пароля, сжатае mime-64
login - устаревшее
digest-md5 - клиент получает открытый ключ от сервера, шифрует строчку, посылает
обратно серверу, тот с помощью закрытого ключа ее расшифровывает
Kerberos - хз

Для включение механизма SASL
smtpd_sasl_auth_enable = yes
конечно, предварительно скомпилировав postifix с его поддержкой

Отличная фича - пользователь прошел аутентификацию и начал рассылать спам с
различными mail from. Защищаемся,
smtpd_sender_login_maps
mail@mail.ru mail.mail.ru
test@hotmail.ru test.hotmail.ru

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


smtpd_sasl_security_options - здесь будут указывать SASL machanisms, которые
будут доступны клиенту при аутентификации, значения
noplaintext - если не разрешена аутентификация PLAIN
noanonymous - обязательно включить, иначе зачем вообще все это
nodictionary - против атак по словарю, ничего более сказать не могу
noactive - защита против Man-In-The-Middle

Есть еще возможность проводить аутентификацию не во время приема, а во время
отправки почты, например, если используется релей и нужно все равно провести
аутентификацию
Включаем механизм
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps
domain имя_пользователя:пароль

Создаем файл /usr/lib/sasl2/smtpd.conf следующего содержания
pwcheck_method: auxprop
и создаем пользователей командой:
saslpasswd2 rodriges@salsero.spb.ru
Просмотреть список пользователей можно командой
sasldblistusers2

TLS

will be soon

Content Filtering

Фильтрация есть в 3-ёх видах:
1. против вирусов/очевидного спама/подделок
применяется уже после приема письма. исп.
header_checks & body_checks
2. фильтрация происходит сразу же после приема письма - плохая мысль, поскольку
работает только на плохо загруженных серверах и не предусмотрено борьбы с DOS
3. Фильтрация происходит после приема письма и выполняется внешней программой.
Вот об этом и поговорим, точнее, о том, как интегрировать внешнии программы для
проверки на вирусы и спам с postfix

1-вы вариант: простой

Схема такая письмо из очереди попадает на обработку по pipe во скипт/программу,
откуда уже через sendmail попадает снова в очередь. Очевидно, чтобы не было
зацикливания, для локальной почты, то есть от демона pickup, проверка должна
быть отключена. Итак, как это реализуется:
1.a. Вариант почта _сразу_ попадает в программу фильтрации. В файле master.cf
создаем транспорт типа pipe, user - от чьего имени будет запускаться программа
argv - путь к программе и аргумента, последним всегда идет -e - весь вывод
программы направляется другой программе, указанной в аргументе. В нашем случае
это sendmail. В argv раскрываются следующие макросы: ${sender} - адрес
отправителя и ${recipient} - адрес получателя. Достоинсво - простота, недостаток
- если что пойдет не так - пиши пропало.
spamassassin unix - n n - 20 pipe user=nobody argv=/usr/bin/spamc -f -e
/usr/sbin/sendmail -oi -f ${sender} ${recipient}
smtp inet n - n - - smtpd
-o content_filter=spamassassin:
1.b. почти что и подпункт a, но письмо вначале направляет в скипт, а в скрипте
его можно прогнать через много-много программ, проверяющих письмо на спам и
вирусы.
spamassassin unix - n n - 10 pipe
flags=Rq user=filter argv=/path/to/script -f ${sender} -- ${recipient}
smtp inet n - n - - smtpd
-o content_filter=spamassassin:

Скрипт примерно такого содержания:

1 #!/bin/sh
2
3 # Simple shell-based filter. It is meant to be invoked as follows:
4 # /path/to/script -f sender recipients...
5
6 # Localize these.
7 INSPECT_DIR=/var/spool/filter
8 SENDMAIL="/usr/sbin/sendmail -i"
9
10 # Exit codes from
11 EX_TEMPFAIL=75
12 EX_UNAVAILABLE=69
13
14 # Clean up when done or when aborting.
15 trap "rm -f in.$$" 0 1 2 3 15
16
17 # Start processing.
18 cd $INSPECT_DIR || {
19 echo $INSPECT_DIR does not exist; exit $EX_TEMPFAIL; }
20
21 cat >in.$$ || {
22 echo Cannot save mail to file; exit $EX_TEMPFAIL; }
23
24 # Specify your content filter here.
#25 # filter < in.$$ || {
33
26 # echo Message content rejected; exit $EX_UNAVAILABLE; }
27
28 $SENDMAIL "$@" < in.$$
29
30 exit $?

2-ой вариант: продвинутый

идея его в том, что передать письмо не через pipe, а через smtp!! приведем на
примере amavisd-new

smtp inet n - n - - smtpd
-o content_filter=amavisd:[127.0.0.1]:10024
amavisd unix - - n - - smtp
127.0.0.1:10025 inet n - - - - smtpd
-o content_filter=
-o local_recipient_maps=
-o relay_recipient_maps=
-o smtpd_restriction_classes=
-o smtpd_client_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks=127.0.0.0/8
-o strict_rfc821_envelopes=yes
То есть все письма пойдут по IP 127.0.0.1 на порт 10024. Осталось лишь сделать,
чтобы письмо возвращались в postfix через порт 10025. Для этого в настройках
amavisd-new делаем
$forward_method = 'smtp:127.0.0.1:10025';
А уже amavisd-new вызовет бессчетное кол-во проверок.

[tune smptd]
disable_vrfy_command (no) - стоит поставить в yes, чтобы адреса не собирали
smtpd_noop_commands (empty) - список команд, на кот. сервер тупо отвечает 250
OK
strict_rfc821_envelopes (no) - стоит поставить в yes, не принимает письма без <>

[ресурсы]
line_length_limit (2048) - строки переносятся, если они больше указанной длины
queue_minfree (0) - сколько нужно свободного места, чтобы почта принималась
message_size_limit (10240000) - макс. размер письма, включая заголовки
smtpd_recipient_limit (1000) - максимальное число получателей для одного письма
smtpd_timeout (300s) - время ожидания ответа от клиента перед отключением
с версии 2.2
smtpd_client_connection_count_limit (50) - скоко подключений одновременно с 1 ip
smtpd_client_connection_rate_limit (0) - сколько любому клиенту разрешено
попыток подключений в течении опр. времени ???
smtpd_client_message_rate_limit (0) - сколько клиенту разрешено отправить
сообщенией за опр. отрезок времение, неважно, будет ли они для сервера или
пойдут дальше
smtpd_client_recipient_rate_limit (0) - макс. число адресов принимателя, кот.
разрешено сделать клиенту
smtpd_client_event_limit_exceptions ($mynetworks) - те сети, которым сделано
исключения из всех ограничений
anvil_rate_time_unit (60s) - в течении этого времени указанные выше команды
считают "определенным временем"

[борьба с глючными клиентами]
smtpd_soft_error_limit (10)
smtpd_hard_error_limit (20)
smtpd_error_sleep_time (1s) - на это время будет задержан прием почты, если
кол-во ошибок в интервале smtpd_soft_error_limit..smtpd_hard_error_limit
smtpd_junk_command_limit (100) - кол-во "пустых" команд (NOOP VRFY ETRN RSET),
которых может сделать клиент, прежде чем счетчик закапает

[access control]
smtpd_delay_reject (yes) - сразу ли отшивать клиента
smtpd_delay_reject (yes)
smtpd_helo_required (no)
smtpd_helo_restrictions (empty)
smtpd_sender_restrictions (empty)
smtpd_recipient_restrictions (permit_mynetworks,reject_unauth_destination)

[прочий бред]
smtpd_banner ($myhostname ESMTP $mail_name) - что светиться при встрече

[tune smtp]
smtp_always_send_ehlo (yes)
smtp_never_send_ehlo (no) - так и надо оставить - всегда представляться перед
отправкой почты
smtp_defer_if_no_mx_address_found (no) - если нет mx, отложить отправку. Не
надо, пусть сразу отвергнет почту
smtp_quote_rfc821_envelope (yes) - всегда ли окружать адресата <>. Да, оставить
как есть
smtp_skip_5xx_greeting (yes) - вести себя вежливо и не пытаться ломиться снова

[ресурсы]
smtp_connect_timeout (30s) - соединение
smtp_helo_timeout (300s) - хело
smtp_mail_timeout (300s) - mail from
smtp_rcpt_timeout (300s) - rcpt to
smtp_data_init_timeout (120s) - data
smtp_data_xfer_timeout (180s) - sending data
smtp_data_done_timeout (600s) - waiting for '.'
smtp_quit_timeout (300s) - waiting for 'quit'
smtp_destination_recipient_limit ($default_destination_recipient_limit) -
скольким адресатам можно доставить почту за одно подключение
smtp_destination_concurrency_limit ($default_destination_concurrency_limit) -
сколько может быть одновременных параллельних подключений к одному IP
smtp_helo_name ($myhostname) - имя, которым представлятьсяъ
smtp_bind_address (empty) - через какие интерфейсы слать письма