Akina

Против программного вандализма - бездисковые рабочие станции и сервер терминалов.

Против физического вандализма - система видеообзора в классе. Плюс "Правила использования компьютерной техники", подписанные официальными представителем каждого учащегося (родители и пр.) и самими учащимися (если позволяет возраст). С подробным описанием санкций (включая материальные) в случае такого вандализма.

И при любом инциденте - не стесняться. Досудебная претензия с полным "меню" восстановления, а при невыполнении в срок - в суд. Обычно "достаточно одной таблэтки" (с)

В чем отличие trunk port от tagged port

Trunk - это понятие, относящееся именно к порту. Это порт, предназначенный для магистральной передачи, соединяющий два коммутатора. Как правило, через него передаётся несколько tagged VLAN.

Tagged - это понятие, относящееся к паре порт-VLAN. Именно конкретный VLAN на конкретном порте может быть либо tagged, либо untagged.

будет ли функционировать между собой tagged и trunk на разных коммутаторах?

Опираясь на вышесказанное: tagged VLAN передаётся через trunk port.

Не надо хранить бинарные файлы в БД.

В дополнение ко всему сказанному - в MySQL извлечение сохранённых бинарных файлов именно в виде файлов, а не массива байтов, тоже занятие нетривиальное. Выполняется по одному, запросом SELECT INTO DUMPFILE, да ещё и отдельно от остальных полей записи.

Есть 2 созданных сети на этом dhcp 10.0.0.1-10.0.0.100 и 10.1.1.1-10.1.1.100.

Это НЕ сети. Это диапазоны выделяемых адресов (scopes).

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

Gateway имеет ip адрес 10.0.0.1.

Это чей gateway? Операционной системы, на которой работает DHCP? Или это значение параметра в настройках скопа, отдаваемое сервером клиенту?

Это gateway куда? Шлюз по умолчанию? Шлюз в подсеть? Что-то ещё?

Каким образом можно указать для сети 10.1.1.1-100 gateway 10.0.0.1 , чтобы например, контейнеры proxmox, которые будут находиться в этой подсети имели выход в интернет ?

Самое простое - объединить скопы одной подсетью.
Соответствующая маска - /23 или шире.

Я считаю, что оптимальным является проведение квалификационного тура. Который отсеет "лишних".

Применительно к показанному - из 17 участников выбираются случайным образом двое, которые играют между собой квалификацию за право выхода на турнир. После чего остаётся 16 участников, играющих 5 туров на выбывание. Будь участников, скажем, 19, квалификацию играли бы три пары.

Если же среди участников имеется некоторое количество, подтверждённая квалификация которых достаточна, они могут быть исключены из числа участников квалификации. Например, если заявились 19 игроков, но пятеро из них КМС и лучше, то они сразу проходят в турнир, а три пары участников квалификации выбираются случайным образом из остальных 14 участников.

Есть товары, которые прилетают по API, их заношу в бд, но иногда часть товаров отсутствует в API и в бд нужно обнулить остатки.

Элементарно.

То, что приходит по API, нужно не пихать сразу в рабочую таблицу, а сохранить во временную таблицу. А потом обновить рабочую таблицу, используя полученные данные как источник данных. Потребуется два запроса - первый обновит записи о товарах, имеющихся в пришедшем списке, и добавит новые (INSERT .. SELECT .. ODKU), второй поставит требуемую пометку в нужном поле (UPDATE .. FROM .. LEFT JOIN .. WHERE .. IS NULL).

Альтернативный вариант - добавить в таблицу (если не имеется, что было бы весьма странно для описываемой системы) поле штампа времени обновления записи (updated_at). Перед обновлением по данным API зафиксировать время начала процесса (получить запросом с сервера MySQL), после чего вторым запросом поставить соотв. пометку в те записи, где этот штамп времени ранее запомненного.

Проблема миграции базы данных с mysql 8 на mariaDB 10?

Проблемы ОБЯЗАНЫ БЫТЬ. MySQL и MariaDB расфоркнулись достаточно давно, изменения и дополнения в синтаксисе они не синхронизируют, так что неудивительно, что чем дальше, тем меньше они совместимы. И соответственно всё меньше шансов. что дамп одной СУБД беспроблемно натянется на другую.

Такой перенос надо делать руками.

1. Выгружаем дамп структуры (без данных) из MySQL.
   
2. Экспортируем данные из MySQL-таблиц в CSV.
   
3. Правим дамп структуры руками, приводим к требованиям синтаксиса MariaDB.
   
4. Загружаем структуру в MariaDB, убеждаемся, что работает. Дропаем.
   
5. Делим дамп на 2 части - в одной только таблицы (и другие критично необходимые для создания таблиц объекты), в другой всё остальное (индексы, представления, триггеры-функции и прочая тряхомудия).
   
6. Грузим первую часть дампа структуры.
   
7. Импортируем данные из CSV в таблицы MariaDB.
   
8. Грузим вторую часть дампа структуры.
   

Будет что-то вроде

SELECT *,
       ( SELECT value
         FROM tablename t2
         WHERE t1.year - 1 = t2.year
         ORDER BY created_at DESC LIMIT 1 
         ) AS prev_value
FROM tablename t1;

Запустите ярлык на CLI из окна CMD и смотрите сообщения. Больше всего похоже на сбой аутентификации.

Навскидку как-то так:

1. На коммутаторе для VLAN интерфейса к pfSense прописываете статический (и не входящий в диапазон выделения на pfSense) адрес из 192.168.1.0.
   
2. На коммутаторе указываете адрес pfSense дефолтным шлюзом. Проверяете наличие связи коммутатора и pfSense в обе стороны, а также коммутатора к внешним адресам в Инете.
   
3. Для VLAN клиентских портов прописываете статический адрес из 192.168.2.0 и включаете на нём DHCP-сервер. Проверяете факт раздачи адресов и коннект коммутатора и клиента в обе стороны.
   
4. Включаете на коммутаторе маршрутизацию между подсетями.
   
5. Прописываете раздачу DHCP-сервером коммутатора своего адреса как адреса шлюза по умолчанию.
   
6. На pfSense в настройках его DHCP настраиваете раздачу адреса коммутатора из 192.168.1.0 как шлюза в подсеть 192.168.2.0/24. Проверяете. что всё работает.
   

Ну и это вроде бы всё...

Да, часть этих пунктов может, скорее всего, выполниться автоматически по факту настройки этого или предыдущих пунктов. Пункт 5 - почти наверняка.

Как обычно - берём двухинтерфейсный маршрутизатор, один к порту в одном VLAN, другой к другому, адреса из соотв. подсетей, маршрутизация, и его на узлах как шлюз в другую подсеть.
Если коммутатор уровня L2+ (а раз на нём есть DHCP-сервер, то это так), то он сам может работать маршрутизатором - прописываешь соотв. адреса внутреннего интерфейса в соотв. VLAN (один уже не надо, на нём DHCP-сервер), и указываешь их шлюзом.
Да, подсети в разных VLAN не должны пересекаться, ессно.

не до конца наверное понимаю работу vlan

VLAN в первом приближении - это не просто, а очень просто.

Первый шаг - это разделение по отдельным VLAN. Мысленно представляешь, что у тебя не один коммутатор, а несколько. Вот прям вместо коммутатора стоИт стопка один на другом. В первом - только VLANID=1, во втором VLANID=2, и так далее. Каждый коммутатор обслуживает строго один VLAN, а все остальные порты, на которых текущий VLAN отсутствует, тупо залиты цементом. Если коммутаторов несколько - то каждый в схеме размножается таким образом, а соединения между портами коммутаторов ещё и раскрашиваются, например, тегованный кабель синий, а нетегованный красный. Соответственно если у тебя есть транковая связь (гибридный или транковый порт) с каждой из сторон) - то в преобразованной схеме один кабель между такими коммутаторами размножается на несколько, каждый в схеме для своего VLAN. А если попадается случай, когда с одной стороны провода VLANID есть, а с другой стороны его нет - получается кабель, с одной стороны вставленный в порт, а с другой нет. И соответственно в схеме для именно этого VLAN связи между коммутаторами нет. Аналогично для случаев соединения "tag на untag" с одной стороны красный кабель, с другой синий, у обоих вторые концы "в воздухе", а связи нет.

Второй, дополнительный, шаг - это соединение меж собой нетегованных портов разных VLAN в преобразованной схеме, если такие соединения исходно существуют, невзирая на номера VLAN. Скажем, если на порте есть нетегованный VLANID=2 (возможно, с другими VLANID, но тегованными), и порт соединён кабелем с другим портом того же или другого коммутатора, на котором есть нетегованный VLANID=3, то в преобразованной схеме ты соединяешь соотв. порты коммутаторов разных слоёв, соответствующих этим VLAN.

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

После такого разделения ты можешь смело анализировать поведение одного VLAN, не обращая внимания на существование остальных.