Александр

Для чего читать Таненбаума?

Для того, чтобы разобраться как работает сеть.

Для этого я открыл Таненбаума, но даже идеи как его слова перевести в код - нет.

Разумеется, так и должно быть. Книга не имеет отношения к программированию, она просто объясняет работу сети.

Вопрос собственно в том, что все советуют читать фундаментальный труд Таненбаума по сетям, но можно ли что-то из этого фундаментального труда вынести на практике?

На практике вы вынесете понимание работы сети, и ничего более.
А уж потом можете использовать это понимание хоть для администрирования, хоть для программирования.

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

создаёте дефолт маршруты с маркировками

/ip route add dst-address=0.0.0.0/0 gateway=1.1.1.1 routing-mark=ISP1
/ip route add dst-address=0.0.0.0/0 gateway=2.2.2.2 routing-mark=ISP2
/ip route add dst-address=0.0.0.0/0 gateway=3.3.3.3 routing-mark=VPN

на входе через mangle вешаете routing-mark по нужному src-address

/ip firewall mangle add chain=prerouting src-address=192.168.0.2 action=mark-routing new-routing-mark=ISP1
/ip firewall mangle add chain=prerouting src-address=192.168.0.3 action=mark-routing new-routing-mark=ISP2

на выходе в nat делаете src-nat/masquerade по маркировке

/ip firewall nat add chain=src-nat action=src-nat routing-mark=ISP1 to-addresses=1.1.1.2
/ip firewall nat add chain=src-nat action=masquerade routing-mark=ISP2

А в чём проблема? Создаёте в веб интерфейсе бридж, указываете ip адрес, маску и шлюз. Там же указываете физический интерфейс с которым нужно сделать бридж и перезагружаетесь. Profit.

Создайте на рейде файловую систему и монтируйте как вам нужно. Если хотите перенести /home на рейд, то лучше почитать про эту процедуру подробнее в интернете, так как могут быть особенности.

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

Система перезагрузилась без корректного завершения работы. Эта ошибка может быть вызвана, если система перестала отвечать на запросы

GLPI
Установка

ну так куда добавляете ключи оттуда и удалять...

cat ~/.ssh/authorized_keys

Разрешение DNS происходит примерно следующим образом:
локальный резолвер + кэш -> рекурсивный резолвер (DNS-сервер провайдера, прописанный в свойствах соединения или DNS-сервер гугла) -> сервер зоны (на котором вы производили изменения).
При этом и локальный резолвер и рекурсивный резолвер провайдера могут кэшировать предыдущие ответы, поэтому изменения не видны сразу. Время кэширования определяется параметром TTL, который можно выставить по дефолту для зоны или отдельный для каждой записи. Перед изменением записей TTL обычно снижают заблаговременно, чтобы новые записи быстрей заработали.
Чтобы вы не делали с локальным компьютером, это не повлияет на кэш рекурсивного резолвера.
Однако, есть еще локальный кэш, который, как правило, кэширует ответы на небольшое время не зависящее от TTL. Он действительно может сбрасываться при переустановке соединения. Однако гораздо проще это делать командой
на Windows
ipconfig /flushdns
на Linux
nscd -i
Как правило, это помогает в случаях корпоративного DNS, при изменениях в корпоравтиной зоне, когда функции сервера зоны и рекурсивного резолвера выполняет один и тот же сервер, поэтому рекурсивный сервер не кэширует разрешаемую запись а отдает ее непосредственно из зоны, и кэширование происходит только в локальном резолвере.

Get-ADUser -Filter * -Properties * | where Company -eq "a" | Set-ADUser -Company "b"