Юрий

Опишу свой опыт, попутно отвечая на вопросы.
Для начала я бы порекомендовал не заполнять бумажки, а воспользоваться личным кабинетом на nalog.ru. Входишь через госуслуги (или логин с паролем, если есть) и выпускайте для себя цифровую подпись для подписывания декларации. Может уйти от нескольких часов до пары дней (похоже, они там RSA руками генерят :) ).

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

Итак, входишь в кабинет, затем - Жизненные ситуации - 3ндфл.

Сразу увидишь свои доходы от работодателя, если где-то ещё устроен. Там все ок, ничего трогать не надо. Переходим на вкладку «Доходы за пределами РФ» и начинаем вбивать на каждый доход отдельную графу (это как отдельный лист в декларации), после каждого нажимая "Добавить доход".
В качестве источника укажи наименование компании. Просто как есть, "ITBerlin LTD", например.
Вид дохода - если это твоя заработная плата и в договоре указано, что это заработная плата - так и вбивай - 2000.
Указать страну, валюту, дату, сумму. Внизу графы будет галочка - курс на дату поступления дохода, кликаешь - все пересчитывается в рубли по курсу на дату поступления (естественно, дата уже должна стоять)
Датой поступления дохода считается день, когда на твой банковский счет свалились деньги (либо, если аккаунт в Пионере твой - значит дата поступления на тот аккаунт... но я бы уточнил на всякий)
Есть ещё момент - вбивать надо всю сумму зарплаты, которая пришла в этот день из одного конкретного места. Нельзя вычитать проценты, которые забирает себе платежная система.
При сдаче декларации с тебя не будут требовать других документов, подтверждающих доход. Если ты станешь интересен налоговой - она сама к тебе придет :)

"Легкая работа, никаких тяжелых файлов" и тут же "редактирование видео"? :) На ноуте 7-летней давности?
MBP конца 2010 года - это наиболее старый MBP, который поддерживается High Sierra-ой. Т.е. есть очень большая вероятность, что следующая MacOS туда уже не встанет.

Вот под "офисные задачи" и "интернет серфинг" - его, наверное, хватит надолго. Особенно, если не заморачиваться обновлениями. (Но тогда и дыры в нем тоже никто не будет фиксить)
"После покупки поставить дополнительный SSD и заменить батарею." - а есть смысл брать ноут подешевле, чтобы потом в него вложить минимум половину его стоимости? Имхо, проще сразу взять новый. Ну или mac mini, который обойдется не намного дороже получившейся стоимости старого ноутбука.

P.S. Извините за старперство и ворчание, но... Сколько лет я слышу "компьютер/ноутбук для учебы" - столько лет и не понимаю, что это за зверь такой? В 99% наблюдаемых мной случаев школьники и новоиспеченные студенты так оправдывали покупку железа родителям (и чтобы обязательно видеокарта была предтоповой или топовой, а то "учеба" тормозить будет).
Наверное, все же стоит определиться, для чего нужен ноут. Если он нужен реально для учебы - это любой ноут, который умеет запускать ПО из пакета MS Office и отправлять на печать, да набивать код в IDE и компилить его. Редко какому студенту надо реально по учебе "редактировать видео" и профессионально владеть фотошопом. Максимум - это обрезка видеоролика, снятого на мобилу, чтобы залить его на youtube и обрезать фото, либо убрать красные глаза (это вроде давно не проблема). С этим справятся встроенные в любую современную ОС средства.
Если действительно решили заняться чем-то профессионально (фотошоп, lightroom, premier) - покупайте себе нормальный инструмент за нормальные деньги. В этом случае инструмент себя окупит очень быстро, помогая в работе, и начнет приносить прибыль. А если просто хочется "штоб был мак" и есть лишние деньги на его покупку - тогда вперед к товарищу. Но учтите, что если понадобится выжать из него больше, чем работа с документами и серфинг - придется рано или поздно (скорее рано) менять инструмент, а быстро "скинуть" старый ноут у вас не получится. Так и зависнет он мертвым грузом (собственно, как сейчас он висит у вашего товарища).

sudo systemctl start openvpn@server.service
Вместо 'server' вписать имя файла конфигурации, если он у вас называется не server.conf.
Т.е. чтобы запустить еще один сервер на той же машине - делаете конфиг-файл server-udp-20001.conf, а затем уже systemctl start openvpn@server-udp-20001.service

Если обратиться к базе знаний CF, там отлично написано английским по-белому:

Ошибка 525 возникает, когда провалилась попытка установления SSL-соединения между CF и твоим сервером. Это означает, что у тебя в настройках выставлено "use Full SSL" (это когда SSL используется не только от клиента до CF, но и от CF до бэкенда) и CF не может к тебе подконнектиться, поскольку не ожидает, что с другой стороны обычный HTTP.

Распространенные причины:
- Твой бэкенд не поддерживает SNI или не сконфигурирован для него
- Способы шифрования, которые принимает CF и которые умеет твой бэкенд - не совпадают нигде
- Твой бэкенд не сконфигурирован на прием SSL вообще

Как один из методов решения проблемы - используй не FullSLL, а Flexible SSL в настройках. В этом случае тебе не надо будет включать SSL на твоей стороне.
Но, вообще, гонять даже от CF открытый трафик - несколько неправильно, я считаю. Можно потратить несколько минут и сделать LetsEncrypt-сертификат, чтобы получить валидный SSL.

location ~ ^/zbx/ {
  try_files $uri $uri.pdf =404;
}

Естественно, что root должен быть прописан, иначе файлы будут искаться в /etc/nginx.
Инфо: https://nginx.ru/ru/docs/http/ngx_http_core_module...

Отправляю файлы с помощью rsync (ssh или rsyncd):
- отправляются только новые файлы или измененные
- файлы меняются атомарно, т.е. пользователь, который сделал запрос во время заливки файлов - гарантировано получит либо старый файл, либо новый. С обычным копированием по фтп есть вероятность зацепить не полностью залитый файл. А если этот неполный файл вдруг зацепит какой-нибудь opcache - ошибок будет выше крыши.

А разве календарь в Android не умеет напоминать? Очевидное же решение.

Я, возможно, выпендриваюсь... но, имхо, ставить squid для акселерации - это же прошлый век.
Есть же nginx для таких дел. И настройка гораздо проще и кеширует на ура.

А по делу - у тебя squid пытается зацепиться за 80-й порт, но он уже кем-то занят.

Базовые очевидные вещи - SPF/DKIM/DMARC - это само собой разумеющееся. Мануалов - вагон. Сам где-то с полгода назад здесь же на тостере писал элементарные вещи для настройки почтового релея.
100.000 в месяц - это примерно 3500 писем в день. Не сильно большая цифра.
Думаю, сначала стоит понять, надо ли отсылать столько и что это будет.
Если это рекламная рассылка с некоего сайта по базе мыл - если эти люди никогда не были на этом сайте - вся рассылка автоматически влетит в спам и дальше можно не читать.
Если это рассылка реальным посетителям некоего сервиса - крайне желательно, чтобы рассылка шла с адреса, домен которого совпадает с доменом сервиса.
Далее - если мы просто настроим сервер на отправку и начнем валить по 10000 и больше писем в день - ничего хорошего не выйдет. У популярных почтовых сервисов тоже есть системы, которые ведут базу серверов и если вдруг появляется какой-то новый сервер, который рассылает сразу кучу писем - этот сервер, как минимум, попадает в подозрительные. Если же начать с малого количества, каждые несколько дней наращивая количество - сервер заработает себе репутацию, что избавит от проблем с отправкой. Опять же - без спама и непрошеной почты, иначе все труды пойдут лесом.

В письмах обязательно заголовок List-Unsubscribe с урлом для отписки от рассылки (популярные почтовики по нему рисуют кнопку отписки), помимо этого обязательно продублировать данную ссылку в тексте письма на видном месте с объяснением, что при клике на эту ссылку пользователь откажется от рассылки. Урл должен работать (отдавать корректный ответ HTTP 200), не должен заставлять пользователя куда-то логиниться и совершать дополнительных действий. Алгоритм четкий - пользователь кликнул на линк - открылся браузер, в нем страница с оповещением, что пользователь "такой-то" отписан от рассылки. И главное - после отписки - никаких рассылок этому пользователю, иначе подпортите репутацию у почтовиков.

Если подходить серьезно - вам придется изучить особенности каждого популярного почтового сервиса. Завести на каждом из них аккаунт постмастера, чтобы отслеживать качество рассылок и вовремя принимать меры по улучшению. Например, mail.ru - очень любят, когда настроен DMARC и есть почта для отсылки отчетов постмастеру (FBL). Вам же придется после каждого цикла рассылки выгребать из этого ящика отчеты о недоставке и спам-репорты и оперативно исключать упоминаемые там адреса из списка рассылки (уменьшите у себя список, плюс, покажете почтовому сервису, что следите за своей рассылкой).
Яндекс.почта - на удивление, вполне лояльна к любой почте, принимая все подряд, но безжалостно запихивает рассылку в папку спам при малейшем подозрении на неправильность. Крайне адекватный сервис постмастера, на котором можно посмотреть много важных параметров рассылки - где находятся письма у пользователей, как они туда попали, насколько интересны письма пользователям (процент просмотра письма) и т.д. Крайне полезный инструмент. Там же можно увидеть список пользователей, которые жмакнули "Спам" у себя в ящиках.
Google - про существование сервиса постмастера у Гугла я сам только недавно узнал, но ничего особо интересного там не увидел.

Насчет тайм-аутов - я лично использую дефолтные таймауты exim. При нормально раскачанном сервере их вполне хватает. Для примера сейчас "рабочая лошадка", рассылающая уведомления пользователям, за сутки разослала 93000 писем - от 1500 до 8000 писем в час.

ibd копировал с источника при выключенном MySQL? В конфиге старого MySQL был включен innodb-file-per-table?
Если ты их копировал с включенным MySQL не используя xtrabackup - тогда с очень большой вероятностью ты не заведешь БД. Можно попробовать создавать пустые таблицы с такими же параметрами, как на источнике, затем выключать MySQL, подсовывать туда ibd и т.д.
Если в конфиге старого MySQL не был включен innodb-file-per-table - тогда все твои данные остались вообще в корне БД в ibdata1.

upstream subexample.com {
и
proxy_pass http://sub.example.com;
Тут непонятно, зачем описывать апстрим и не использовать его. Или это опечатка?
Второе - непонятно назначение конструкции:

if (!-f $request_filename) {
  proxy_pass http://sub.example.com;
  break;
}

Читаю так - если файл не существует, то сделать proxy_pass на самого себя и получить бесконечный редирект (это в случае, если там не опечатка и проксится на sub.example.com), либо по http-протоколу обратиться к бэкенду, который висит на сокете и тогда получим фигню, потому что результирующий урл довольно необычного вида http://unix://....
Сразу возникает вопрос... а если файл найден? Откуда его отдать? Других опций как-то не видно.

Я бы порекомендовал:
- не называйте апстримы также, как реальные серверы - одна ошибка и получим непредсказуемое поведение, которое очень сложно отловить. В идеале, апстримы можно назвать одним словом, чтобы не путать с именем сервера.
- Постарайтесь обойтись без if в конфиге, особенно для проверки существования файла. Есть же try_files.

child 3275 exited on signal 9 (SIGKILL) after 89.296408 seconds from start

Что-то PHP делает с залитым вами файлом целых 90 секунд, после чего fpm его успешно убивает, как повисший. Смотрите обработку файла картинки при POST-запросе. Возможно не стоит обрабатывать его сразу, а для начала сохранить оригинал, чтобы отпустить коннект, а уже потом проводить над ним какие-то магические действия в виде обрезки, конвертации, накладывания водяных знаков и т.д.

Если для wifi выделена отдельная подсеть - тогда в bind можно настроить разные view для разных адресов и, соответственно, отдавать разные ответы на разные view.
Гуглите bind9 split dns.