Возможно, кому-то пригодиться. В почтовом клиенте Mozilla Thunderbird (как и во многих других) есть возможность при создании письма указывать запрос подтверждения о доставке письма на почтовый сервер получателя (Delivery Status Notification, DSN). Очень удобно, т.к. обычно при отправке письма из почтовой программы до конца не ясно, что с ним произошло - отправилось ли оно или почтовая программа сглючила и прочее. А тут раз - и приходит через несколько секунд (как правило) подтверждение о том, что ваше отправленное письмо было принято почтовым сервером получателя. Не факт, что письмо было прочитано - попалов спам или было удалено. Мы этого не знаем. Но мы с уверенностью можем сказать, когда наше письмо было доставлено на почтовй сервер. Примерно как если вы отправляете письмо с курьером и точно знаете, что письмо доставили на ресепшн получателя. Да, это не подтверждает прочтение. Но все же лучше, чем ничего. По-крайней мере, если ваш контрагент говорит - я не я и лошадь не моя, вы ему всегда можете показать отбивочку - мол или врете, мистер или в спаме ищите.

Сейчас нет времени писать статью, с примерами, скриншотами, но поделиться "находкой" все же хочется - полгода назад случайно наткнулся на программу анализа трафика, в том числе под Windows. Называется программа NetworkMiner. Бесплатная версия тоже кое-что умеет! Запустите программу (под админом), выберите сетевой интерфейс, жмите старт и откройте пару сайтов, больше не надо. Теперь закрывайте браузер и смотрите, сколько всего наловил NetworkMiner. Честное слово, вам должно понравится. Группирует DNS запросы, параметры трафика, GET, куки, сессии, файлы, фреймы (!) и др. Может, и дополню потом эту заметку (сам для себя написал, чтобы не забыть опять). Помочь программка может если надо понять, что и куда ломиться, а, например, tcpdump вам не подходит или не очень нравится. Заявлена работа в Windows (проверил сам), в Linux, Mac и FreeBSD. Нигде, кроме Windows, не пробовал - не знаю ;) А в Windows понравилось. Чуть не забыл, вот страница программы: http://www.netresec.com/?page=Networkminer

На днях пришлось менять диски на сервере CentOS 6.7. Старые диски хоть и рабочие еще, но с нагрузкой не справлялись. Поэтому раскошелились и купили SSD диски такой же емкости, как и старые. Но т.к. стоимость 1 Гб на SSD диске намного дороже, то посмотрев на размер /var (180 Гб) и / (корневой раздел) 300 Гб, само собой напросилось решение увеличить размер / за счет уменьшения размера /var. Идея, конечно, хорошая, но раньше я никогда таким не баловался, поэтому провел выходные на форумах, проверил сначала все на виртуальной машине без raid, потом подумал, что на моем сервере работает софтовый raid1 и сделал тестовый стенд (на старый комп поставил CentOS 6.7 с двумя дисками в программном raid1) и проверил все на нем, потом уже выполнил повторно на рабочем сервере. Но все же волнительно было, чего уж. Итак, поехали!

У каждого есть свой способ делать бекапы и архивы. У меня тоже есть свой :)

Неоднократно сталкивался с ситуациями, когда архив tar.gz, созданный в Linux (tar -czvf) , нормально в Linux открывающийся, в Windows либо не открывался либо все время говорил об ошибках конца архива и прочее. А я хотел, чтобы архивы сервера можно было бы спокойно просматривать на Windows. В итоге родился вариант: tar | 7za. Почему не просто tar? Мне не поддался tar в плане multi-volume (вернее, я не очень-то и искал), да и не сжимает он все же сам. А почему тогда не просто 7za? А потому, что в man 7za белым по черному написано, что 7za не сохраняет прав доступа и владельцев файлов. Поэтому сначала tar, потом 7zip.

Для того, чтобы на наш компьютер (Linux) подключить папку с удаленного сервера (Linux), можно использовать sshfs.

Для измерения текущей нагрузки на диски (что происходит, кто куда копирует и прочее) в Linux можно использовать iotop (и здесь же lsof) и iostat. А для тестирования возможностей дисковой системы fio. Несмотря на то, что первое, о чем можно подумать в плане попугаев - это IOPS или же Мб/сек за чтение или запись, обратите внимание на время ожидания. Примерно как если бы вы стояли в очереди в кассу: вас обслужили бы за 2 минуты, но очередь может быть минут на 30. И со стороны наблюдателя ваш процесс обслуживания будет "висеть". Именно так могут ощущать себя клиенты сервера, если время ожидания будет намного превышать время выполнения конкретной задачи. Поэтому определение длинной очереди и задержек часто бывает более важным, чем знать, что ваш диск "вау, может писать 400 Мбит/с". Нагрузка на диск может оказаться в 4000 Мбит/с в течение длительных периодов времени и все это время клиенты сервера будут недовольны.

Стоял себе сервер, подключенный к одному провайдеру (ip 1.1.1.1). Все в порядке, все работает. И вот привалило счастье - появился второй провайдер (для большей доступности). Подключили еще одну сетевую карту, назначили ip 2.2.2.2. Проверяем доступность сайта или почты через 2.2.2.2. А в ответ - тишина. На запросы не отвечает, сайт по нему не открывается. Хотя и брандмауэр уже настроили, и вроде бы все должно работать. Все дело в маршруте по-умолчанию. Если default gateway у сервера указан как 1.1.1.1, то даже если вы снаружи пытаетесь пингануть 2.2.2.2, то сервер все равно упорно отправит ответ через 1.1.1.1, соответственно, пакет будет потерян, т.к. выйдет через другой интерфейс. Что делать?

Это на своей рабочей станции вы всегда видите часы перед глазами и расхождение даже на 5 минут будет сразу видно. А на сервер заходят тогда, когда что-то случилось или просто для профилактики, но вряд-ли часто. И в консоли время не показывается. А сбиться оно может. А последствия могут быть разными. Простой вариант: дата создания или редактирования файла будет не верной. А если это почтовый сервер? Вы письмо приняли раньше, чем его отправили? Или запостили новость на сайт завтрашним днем? Дата важна для логов, для множества вещей. Итак, время должно быть точным.

Если письма с вашего почтового сервера вдруг стали отклонять, то может быть полезным проверить корректность обратного разрешения IP в доменное имя (иначе, проверить PTR).

Если запись "А" указывает, что такое-то имя хоста (test1666.org, к примеру) имеет такой-то IP (например, 8.8.8.8), то "PTR" запись, наоборот, может подтвердить, что конкретному IP действительно соответствует это доменное имя. Грубо: спамер отправляет со своего "левого" сервера письмо, подделав его, будто письмо отправлено с домена test1666.org. В любом случае, принимающий почтовик увидит IP-адрес отправителя (ip сервера спамера) во время установления SMTP-сессии и проверит, а соответствует ли такому IP-адресу легитимный MX сервер домена test1666.org. Если нет, письму присвоят больший спам-рейтинг или отклонят его вообще. Ну или совсем по-пацански: Вася всем говорит, что учится в Универе. Но до тех пор, пока сам Универ это не подтвердит, верить Васе можно только частично.

(актуальность статьи: 19.10.2023) Иногда мне кажется, что создатели Mikrotik намеренно лишают себя прибыли, не создавая однозначных пошаговых руководств по настройке своих детищ. Почти 100% потребителей этих роутеров пытаются настроить VPN, использовать два или более WAN одновременно или в качестве резервных. Именно это ищут по всей сети (и часто вне рунета) счастливые владельцы этих замечательных устройств. Представьте, на сколько бы увеличилась армия владельцев, если бы для настройки этих функций было два-три визарда в веб-интерфейсе. А сейчас.. сейчас именно благодаря сложности настройки (и, соотв., меньшему количеству желающих купить) мы имеем недорогое, малокапризное для несложных задач устройство, которое надо заставить работать 24х7х365. Например, в качестве VPN-сервера. Поехали!