nApoBo3

Попробуйте отключить smb multichannel. Со стороны клиента и сервера бэкапов.
Тут подробнее

Сейчас "верстка сайтов" - это уже не профессия, а обязательный навык к другой профессии. Например, для фронтенд-разработчика, либо UI/UX-дизайнера. Поэтому знание html/css ничто без уверенного знания javascript. А далее идут еще более комплексные вещи типа React/Vue и прочего.
Вот что должен знать начинающий, а вот пример уже более-менее зрелого разработчика.

Для начала выяснить какой именно процесс грузит систему и уже только после этого решать что делать дальше - перезапустить процесс, сервер, найти причину почему он так грузит - не оптимизированный запрос, пользователи, ддос, атака, взлом, вирусы, майнеры и прочее.

Новичкам обычно выбирать не приходится.

Провайдер просто может блокировать l2tp.. это уже к сожалению вполне распространнено...

По двору прошелся жулик и попытался хакнуть эксплойтом для "майбаха" (условно) все тачки в вашем дворе. Майбахов не нашлось, этот жулик пошел дальше и забыл уже про ваш дворик.

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

Вообще, если ваш сетап на виртуальных машинах в повторяемой среде и с декларативной конфигурацией вроде кубера или докера, то вы легче сможете пережить всякие такие факапы.
Схема такая.
Есть признаки взлома - бэкап логов, снапшот базы, бэкап стораджа, остановка сервисов (если позволяет продакшн), анализ атаки и последствий. Устраняем уязвимость по вектору атаки (гугление по логам и курение тредов), правим конфиги развёртывания и запускаем прод. Потом долго и тщательно разбираемся по логам, снапшотам и бэкапам что затронуто. Делаем тестовый чистый сетап по старой конфигурации и сравниваем пофайлово с атакованной системой, выясняем в какие места вмешались злодеи. Дифаем базу и смотрим на подозрительные различия. Делаем выводы, объявляем об утекших данных, если есть такие признаки (чтобы не подставлять пользователей), принимаем превентивные меры против похожих векторов атак.

Итого, залог успеха - это хранение конфигураций в гит-репозитории, своевременные бэкапы, хранение бэкапов на отдельных изолированных стораджах, оркестрация и автоматизация развертывания, подробное эшелонирование логирование с бэкапами логов, смоук тесты на нестандартную активность в БД, по сетевым интерфейсам, трафику, процессору, памяти, файловым системам, логам...

Это взгляд дилетанта по безопасности, если чего пропустил -- поправьте. Если где не прав -- расскажите.

Не влияет.
Никакой анонимности в интернете нет.

1. RTFM!

forEach в стримах:
Performs an action for each element of this stream.
This is a terminal operation.
The behavior of this operation is explicitly nondeterministic. For parallel stream pipelines, this operation does not guarantee to respect the encounter order of the stream, as doing so would sacrifice the benefit of parallelism. For any given element, the action may be performed at whatever time and in whatever thread the library chooses. If the action accesses shared state, it is responsible for providing the required synchronization.


forEach для Iterable:
Performs the given action for each element of the Iterable until all elements have been processed or the action throws an exception. Actions are performed in the order of iteration, if that order is specified. Exceptions thrown by the action are relayed to the caller.
The behavior of this method is unspecified if the action performs side-effects that modify the underlying source of elements, unless an overriding class has specified a concurrent modification policy.


2. Ну это совсем просто загуглить

3. Вопрос про отпуск и когда вы можете выйти на работу - это самый обычный вопрос, показывающий, что собеседующий не вчера родился и знает, что люди, иногда не могут выйти на работу "завтра", что иногда у них есть "планы на отпуск и уже билеты куплены". Элементарное управление кадрами.

Чем по-вашему маршрутизатор отличается от ПК?
Тем, что маршрутизатор маршрутизирует для других, а ПК маршрутизирует для себя. Сам процесс маршрутизации тот же самый.
Ну ладно, посмотрим на ПК. Вот какая-то программа сгенерировала tcp-пакет с адресом назначения 11.23.45.67, а другая программа получила пакет с адреса 192.168.1.100 и хочет на него ответить своим пакетом. А таблицы маршрутизации нет, предположим. И что дальше делать с пакетами первой и второй программы? Просто хочется понять вашу логику, как вы хотите обойтись без таблицы маршрутизации, но продолжать отправлять пакеты куда следует.

Установить систему на 1 ноут
Снять образ, например с помощью RdriveImage
Развернуть с образа на остальные ноуты

Ну или можно поднять TFTP сервер, и разворачивать по сети с помощью clonezilla, предварительно ей сняв копию с рабочего ноута

Возможен, когда ты сеньор с большим и шикарным опытом.

1) При вставке записи вручную не передавать id. Тогда СУБД сгенерирует его автоматически.
2) После вставки значения вручную менять значение автоинкремента
ALTER SEQUENCE serial RESTART WITH 2;

далее коммутатор ищет целевой мак адрес в своей таблице, и находит, но как?

просматривает таблицу коммутации в поисках MAC-адреса. если находит в таблице строку с этим MAC-адресом - берёт из этой строки номер порта.

как он записывает его в своей таблице? типо switch2:port3?

нет. MAC:port. это ведь таблица соответствия MAC-адресов и портов, логично?

если он в линке с другим коммутатором?

тогда если с этого другого коммутатора приходили Ethernet-кадры, то для каждого кадра он занесёт в таблицу коммутации MAC-адрес источника из кадра и номер порта, на который этот кадр пришёл (т. е. номер порта, к которому подключен другой коммутатор).

Или их таблица коммутации обьединяется и нумерация портов второго коммутатора начинается следующего номера, на котором закончились порты первого коммутатора?

нет. у каждого коммутатора своя таблица соответствия портов с MAC-адресами.

В сети явно не хватает уровня агрегации с настроенными vlan и qos.

Сделайте, раз не хватает.

1) не делать свой почтовый сервер
2) хорошо подумать, и не делать свой почтовый сервер
3) если все равно хочется сделать, но еще раз подумать, и не делать почтовый сервер.
Ну и нужно настроить:
- записи MX, SPF, DKIM
- настроить подписи DKIM
- установить SMTP-вервер (opensmtpd например),
- установить POP и/или IMAP серверы
- настроить TLS на всем этом с сертификатами
- очень желательно настроить антиспам типа spamassist
А также по просьбе старого друга и авторитетного администратора крупных почтовых (и не только) сервисов Alexey Dmitriev

Просьба добавить в свой правильный список - настройку записи DMARC и PTR - для полноты картины.

Без этого тоже никуда никто не едет.
И еще раз крепко подумать, нужна ли Вам эта головная боль и разбирательства, "почему меня все блокируют"...
Один из выходов, хостить почту у провайдеров почты, а себе забирать архивы раз в день...

PS, И да, если уж речь зашла о настройках, Всякие PTR, SPF, MX, DKIM, DMARC и прочие вещи я не всегда знаю сам как автоматизировать. В основном ручками все собираю по привычке и правлю конфиги. А в больших инсталляциях еще и разношу на несколько серверов.
И все равно, почта требует практически еженедельного (если не ежедневного, в больших инсталляциях) присмотра и ухода, чистки очередей, разгрузки сервисов, борьбы со спамом и прочей хренью.

PPS. Лет 25 назад доставляло мне удовольствие, забирать отдавать почту по UUCP по модемному коннекту на организацию в 100 человек :)
Теперь нет никакого удовольствия. Это все равно что содержать ftp-сервер. Старый протокол, старые технологии, куча говна и палок.

Ну и коли пошла такая пьянка, некоторые корпоративные почтовики оборудуют всякими фильтрами:
- первое письмо не проходит, и его нужно ставить в отдельную очередь на минут 20-30 для повторного ответа - не выдержал таймаут - БАН
- первое письмо просто валится в спам - повторная отправка - БАН
- нельзя отправлять почту более 10 ресипиентам - БАН
- пигн-понг короткими сообщениями - иначе БАН

Ну и прочие чудеса эквилибристики почтовых администраторов.