Записи DNS MX/SPF/DMARC без фактических электронных писем на домене
Я создал веб-сайт для кого-то, но и кто-то (я думаю, какой-то SEO парень) сказал этому человеку, что я сделал большую ошибку, потому что отсутствуют DNS-записи на домене (mx, SPF, dmarc). Теперь мне нужно «исправить» свою ошибку.
Конечно, эти записи используются в целях электронной почты, но в этом домене НЕТ электронной почты (просто бесплатная учетная запись Gmail).
Итак, есть ли причина добавлять эти записи? Как они должны выглядеть? Единственная причина, по которой я могу думать, это предотвращение нежелательной почты с использованием моего удостоверения домена. Но я думал, что фильтры нежелательной почты не будут передавать электронную почту из моего домена в любом случае, если эти записи отсутствуют, так какой пункт?
-121--303910- Это никогда раньше не случалось со мной, но я не могу выполнить простую задачу, такую как сжатие файла размером 18,5 ГБ на Ubuntu Linux 18,04 с помощью любых популярных инструментов сжатия, таких как gzip , bzip2 и 7z . Все они сообщают об аналогичном предупреждении (а не об ошибке), утверждая, что размер файла изменился во время сжатия, когда к файлу фактически не обращается ни один другой процесс. Например, при попытке «tar-gz» инструмент сообщает: Файл уменьшен на < nnnnnnn > байт; заполнение нулями , выход с кодом ошибки 1, который, по словам tar manpage, происходит из-за изменения файла при сжатии:
exit code 1: Некоторые файлы различаются. Если tar был вызван с параметром --compare (--diff, -d) параметр командной строки, это означает, что некоторые файлы в архиве отличаются от их дисковых аналогов. Если дегтю присвоено одно из значений --create, --append или --update параметры, этот код выхода означает, что некоторые файлы были изменены во время архивирования, и поэтому результирующий архив не содержат точную копию набора файлов.
Файл является VMDK, и, конечно, связанная виртуальная машина полностью закрывается, когда я сжимаю его. С другой стороны, я заметил, что все инструменты сжатия отказывают, когда сжатый файл достигает размера около 280 МБ.
Я уже проверил другие подобные вопросы на ServerFault, но все еще не получил никаких подсказок, чтобы выяснить, что происходит. Наиболее голосуемый ответ на связанный вопрос говорит, что это не ошибка и что средство сжатия просто «упрощает» кучу нулевых байтов, но если я пытаюсь запустить ВМ после распаковки файла VMDK, это не означает, что диск поврежден.
Я полностью застрял на этом. Есть идеи, что может произойти?
UPDATE
При попытке копирования файла в другой каталог с помощью команды cp произошла ошибка ввода-вывода при чтении файла. С другой стороны, dmesg сообщил об ошибках ввода-вывода при чтении определенного блока файла. Все указывает на ошибку диска (хотя e2fsck говорит, что все в порядке и есть 0 плохих блоков). Поскольку у меня уже есть резервная копия виртуальной машины, я попытаюсь изменить диск хост-компьютера и переустановить новую копию Ubuntu и посмотреть, что произойдет. Я держу этот вопрос в курсе, пока не получу какие-то результаты.
OK, я отвечаю на свой собственный вопрос, который может послужить кому-то другому для осознания того, действительно ли у него проблемы с аппаратным обеспечением.
После многократных попыток сжатия проблемного файла (даже с разными компрессорами), я просто попытался скопировать файл в другой каталог с помощью cp, который при чтении файла выдал ошибку ввода/вывода:
cp: reading `filename': Input/output error
Беглый взгляд на вывод dmesg подтвердил аппаратную ошибку, сообщив об ошибке ввода/вывода, прочитав определённый блок на диске.
Я загрузил операционную систему в аварийном режиме и запустил e2fsck -vf /dev/sda1, но он не сообщил ни о каком неисправном блоке. Из комментариев к моему вопросу пользователь Никита Киприянов предложил запустить e2fsck -c -f, который у меня не было возможности запустить, так как я уже сменил диск. Флаг -c специфически работает с плохими блоками, согласно manpage:
заставляет e2fsck использовать программу badblocks(8) для сканирования устройства только на чтение с целью поиска любых плохих блоков. Если найдены плохие блоки, они добавляются в код плохого блока, чтобы предотвратить их размещение в файле или каталоге. Если эта опция указана дважды, то сканирование плохих блоков будет производиться с помощью неразрушающего теста на чтение-запись.
Может быть, читатель может запустить эту команду, как предлагает Никита, в качестве обходного пути, но когда диск начинает давать аппаратные ошибки, лучшим вариантом будет попытаться сохранить как можно больше информации и переместить систему на новую, свежую.
Удачи!