Структура/proc/kcore на 64-разрядной машине и отношении к физической памяти
Режим Daemon по сравнению с MSP
Аннотация IP-адреса, который Вы упомянули выше, является на самом деле не конфигурацией sendmail сам сервер. Если Вы смотрите на современное развертывание sendmail это обычно разделяется на 2 компонента. Традиционный сервер (режим демона) и другой сервер, работающий в почтовом режиме программы представления (MSP). Вы видите это с простым ps команда:
$ ps -eaf | grep send
root 24488 1 0 21:10 ? 00:00:00 sendmail: accepting connections
smmsp 24504 1 0 21:10 ? 00:00:00 sendmail: Queue runner@01:00:00 for /var/spool/clientmqueue
Первая строка является sendmail в режиме демона, вторым является sendmail в режиме MSP. Можно всегда говорить им независимо, потому что большинство дистрибутивов, которые поставляют sendmail, делает вариант MSP выполненным как специальный пользователь с меньшим privledges. Вот, это работает на моем сервере CentOS 5.x как на пользователе smmsp.
Примечание: Это сделано для разделения обязанностей обработки почтового представления (MSP) и доставка почты (режим демона). Пользователи соединяются с экземпляром MSP, когда они отправляют почту с командами такой как mail и mailx локально на поле.
При контакте с sendmail на основанном на Red Hat дистрибутиве, таком как CentOS, конфигурационные файлы расположены здесь: /etc/mail. Существует 2 файла, что мы интересуемся для этой модификации:
- /etc/mail/sendmail.mc
- /etc/mail/submit.mc
Первый файл управляет сервером режима демона, в то время как второй файл предназначен для сервера MSP.
Кстати, они *.mc файлы не являются фактическими конфигурационными файлами, которые эти 2 сервера используют непосредственно; в целом sendmail конфигурация может быть сложной. Учитывая он - возраст, и это - универсальность, это может быть настроено различными способами и так они *.mc файлы являются файлами предварительного конфигурирования, которые "компилируются" в фактический sendmail конфигурационные файлы. Скомпилированные версии этих файлов находятся также в том же каталоге:
- /etc/mail/sendmail.cf
- /etc/mail/submit.cf
Обычно мудро не внести изменения в эти 2 файла непосредственно, а скорее внести изменения посредством их соответствия .mc файл. Вы обычно редактируете .mc файлы и затем выполненный make управляйте в то время как в /etc/mail каталог. Снова это - изм Red Hat к моему знанию, таким образом, другой дистрибутив мог бы сделать вещи по-другому.
Примечание:* .mc файлы находятся на макроязыке по имени M4, таким образом, инструмент к скомпилированному их, конечно, называют m4. Можно вручную скомпилировать эти файлы с командой, такие как это:
$ m4 /etc/mail/submit.mc > /etc/mail/submit.cf
Это - все, что это продолжает воображение make и Makefile файлы, которые Red Hat обеспечивает в /etc/mail каталог.
Изменения в submit.cf
Таким образом, какие изменения необходимо внести? Следующая строка должна быть добавлена к submit.mc файл:
CLIENT_OPTIONS(`Family=inet, Address=, Name=MTA')dnl
Обязательно добавьте Ваш IP, где он говорит submit.mc файл.
$ cd /etc/mail && make
После того как Вы повторно создали .cf файл необходимо будет перезапустить sendmail:
$ /etc/init.d/sendmail restart
-or-
$ /etc/init.d/sendmail reload
Конечный продукт
После создания вышеупомянутого изменения Вас оставят со следующим заголовком. В этом примере мой внешний IP-адрес был 50.122.22.45, например.
Return-Path:
Received: from mail.sdom.com (mail.sdom.com [50.122.22.45])
by sdom.com (8.14.3/8.14.3) with ESMTP id r5J188Gx018193
for ; Tue, 18 Jun 2013 21:08:08 -0400
Received: (from root@localhost)
by mail.sdom.com (8.14.3/8.14.3/Submit) id r5J15ua4018000;
Tue, 18 Jun 2013 21:05:56 -0400
Date: Tue, 18 Jun 2013 21:05:56 -0400
Message-Id: <201306190105.r5J15ua4018000@mail.sdom.com>
to:user@sdom.com
from:admin@hostname.tld
subject:Testing
X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00
autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail.sdom.com
X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-4.0 (sdom.com [127.0.0.1]); Tue, 18 Jun 2013 21:08:09 -0400 (EDT)
test test test
Ссылки
После гораздо большего поиска Я думаю, что я убедил себя, что нет простого способа получить то, что я хочу.
Итак, что я покончил? Я установил известь из Github ( https://github.com/504ensicslabs/lime )
git clone https://github.com/504ensicsLabs/LiMe
cd /LiME/src
make -C /lib/modules/`uname -r`/build M=$PWD modules
Вышеуказанные команды создают модуль ядра Lime.ko. Полный дамп памяти может быть получен к тому времени:
insmod ./lime.ko "path=/root/temp/outputDump.bin format=raw dio=0"
, которые просто вставляют модуль ядра, и строка - это параметры, указывающие местоположение выходного файла и формата ... и он работал! УРА.