res2001

Почитать книжку "Многопоточное программирование на С++". Там не про сокеты в многопотоке, а просто про сам многопоток. Многопоточная обработка сокетов не сильно отличается от любого другого многопотока.

Самый простой вариант - отдельный поток на каждого клиента.
В одном потоке крутится accept, при получении нового клиентского дескриптора, запускаешь новый поток и передаешь ему дескриптор. Поток производит всю обработку запросов от клиента. При разрыве связи, поток завершается.
Достоинтсва: просто в реализации, минимум межпоточной синхронизации.
Недостатки: отдельный поток на дескриптор - это довольно дорого, но если не планируется обрабатывать соти клиентов одновременно, то вполне годный вариант.

Как альтернатива для случая не слишком большого количества клиентов - один поток + неблокирующие сокеты + асинхронная обработка.
Про работу сокетов в неблокирующем режиме можешь почитать: "UNIX: Разработка сетевых приложений" книжка старая, но актуальная. В магазине скорее всего не найдешь, но в интернете полно сканов.
Книжка хороша не только по неблокирующим сокетам, а в принципе как описание разработки сетевых приложений.

Отдельный вопрос - кросс-платформенное приложение. Книг на эту тему вроде не видел, но подходы имеются. Не то что бы это сложно, но есть своя специфика.

Мне кажется с блокировками вы несколько путаетесь. В данном случае могут быть заблокированы 2 объекта на одной файловой операции:
1. поток, использующий синхронную операцию чтения/записи в файл
2. файл открытый для монопольного доступа

Думаю ваш вопрос не связан с п.1, т.к. это больше про параллельное программирование, а не про файлы и БД.
Файловые операции легко могут не блокировать поток - асинхронный ввод/вывод.
Файл можно открыть с монопольным доступом и с общим доступом. В общем доступе этот же файл может открыть и другое приложение одновременно с вашим.
При общем доступе вы можете блокировать какую-то область файла и работать с этой областью "монопольно".
БД открывают свои файлы в монопольном режиме.
В разных потоках одного приложения вы можете открыть файл один раз и работать с одним и тем же дескриптором файлов из разных потоков. Но это может создать кучу проблем с целостностью структуры файла, если много потоков будут не согласованно писать в файл.
Файловые операции ОЧЕНЬ медленные. Поэтому все нормальные базы данных работают через свой собственный кэш. Поэтому там, обычно нет кучи потоков, которые лопатят файл БД. Движок SQL берет данные из кэша, есть некий "менеджер кэша" - отдельный поток, которому движок дает запрос на данные, если данных в кэше прямо сейчас нет, то менеджер кэша читает данные из файла в кэш и отдает эти данные запрашиваемому потоку. Чтение файла наверняка то же идет не на прямую, а запросы на чтение ставятся в очередь и возможно какой-то другой поток (или тот же менджер кэша) по очереди читает необходимые данные. Аналогично и с записью - через кэш и последующую очередь на запись.
Если запустить MS Sql Server с настройками по умолчанию с достаточно большой по объему базой он довольно быстро отожрет в компе вообще всю свободную память (конечно, если БД меньше, чем объем ОЗУ, то всю память не отожрет). Не то что бы ему очень нужно прямо сейчас вот столько памяти (он может в это время вообще простаивать), просто он начитал данные в кэш.
Как-то так я это вижу.

Тут не важно GUI или нет (может быть любой интерфейс - сеть, файлы, потоки, процессы, и т.п. системные интерфейсы). Подход один и тот же. Если нужна кроссплатформенность, то ищите кроссплатформенные библиотеки, реализующие нужный интерфейс. Если таких нет (видимо плохо искал), то пишите свою. Это довольно сложно.

или объясните почему ни чего ен получится?

Потому что передача по сети - это протокол обмена. И это не UDP или TCP, это протокол более высокого уровня. Протокол обмена должны поддерживать обе стороны, иначе это будет разговор слепого с глухим. Протокол включает в себя формат пакета/потока (список данных, описание данных и двоичного представления этих данных). Без знания протокола вряд ли получится что-то передать так, что бы принимающая сторона это восприняла как свой родной пакет и предприняла бы соответствующие действия.
Протоколы могут быть двоичные и текстовые. В текстовом протоколе (HTTP, SMTP, ...) визуально видны части пакета и в принципе по анализу перехваченных данных можно сделать какие-то выводы.
В двоичном протоколе без описания формата вряд ли что-то можно разобрать. Разве что что-то очень простое. У вас двоичный протокол.
Поэтому, обычно, что бы что-то отправить по какому-то протоколу требуется специализированная утилита, реализующая этот протокол. Например для HTTP утилита - это браузер или какой-нибудь curl.
Бывает, что протокол открытый, т.е. описание доступно в свободном доступе (или его можно купить). Так же часто используются закрытые протоколы, описание которых есть только у его разработчиков. Если у вас открытый протокол то шансы что-то скостылить есть.

Поищите у производителя устройства (спросите на форуме поддержки) фирменную утилиту работающую из командной строки или описание протокола (или конкретно данного пакета для установки времени).

Раз у вас пакет установки времени, то в данных должно присутствовать время. Это может быть какой-то вариант timestamp, например Unix timestamp. Можете попробовать поискать в дампе таймстамп на момент отправки пакета. Имея несколько вариантов пакета можно попытаться сделать какой-то его анализ и попробовать разобрать пакет на составляющие его поля. Сделать реверс инжиниринг.

Еще немного. Обычно для установки времени не достаточно просто отправить 1 пакет с новым временем. Т.е. можно и так, конечно. Но в этом случае потенциально может быть большая не точность, т.к. доставка пакета не моментальна, могут быть задержки при передаче и приеме и все это практически не предсказуемо. И когда приемная сторона установит у себя полученное время, то это время уже может стать не точным. Поэтому для минимизации побочных эффектов задержек используют отдельные протоколы для установки времени и там уже как правило не один пакет.
Для примера можете немного посмотреть в сторону протокола NTP - он используется для синхронизации времени через интернет, это открытый протокол, доступно его описание. Например ваша винда наверняка синхронизируется с каким-то NTP сервером от микрософт, фиг знает где находящимся.

Линукс может быть установлен на обоих дисках. Ничто не мешает монтировать разные разделы на разных дисках в разные пути, используемые системой, в т.ч. на этапе установки ОС. Тут вам не винда.
df покажет какие разделы на каких дисках куда примонтированы.
Так же надо посмотреть в БИОС с какого диска загружается ОС - там установлен загрузчик (скорее всего grub).

Можете клонировать содержимое старого диска на новый и после этого заменить диски. Затем создадите на новом диске новый раздел на свободном пространстве и куда-нибудь примонтируете его. Клонировать можно из того же линукса, прицепив новый диск третьим и используя dd для побайтного клонирования.

В корневые нужно пихать только сертификат ЦА. Это контейнер для них.

Самоподписанный сертификат - это другое. Это когда у вас нет ЦА и вы просто выпускаете сертификат сервера и он сам себя подписывает. Такой простейший вариант сертификата.

Сертификат ЦА - самоподписанный, т.к. его никто не подписывавет, но используете вы сертификат сервера и возможно клиента, а эти оба сертификата подписываются ЦА и они не самоподписанные. В работе используется сертификат ЦА только для проверки подписи предоставленного сертификата сервера и/или клиента, дальше для всего используются серверный и клиентский сертификаты.
Не знаю особенностей Jitsi Meet, но по ссылке нет самоподписанных сертификатов. Там упор делается на использование LetsEncrypt, но по большому счету разницы нет - используете ли вы ЦА от LetsEncrypt или свой собственный. В случае своего ЦА , вы должны обеспечить возможность проверки сертификатов, правильно установив сертификат ЦА, тогда как сертификат LetsEncrypt (и других известных публичных ЦА) обычно уже установлен в системе. Процесс контроля за сроком сертификатов, их перевыпуском, ведением списка отозванных сертификатов и его доступностью то же ложится на вас.

Любой сертификат содержит в себе публичный ключ владельца сертификата. Вторая часть ключа - секретный ключ - идет в отдельном файле. Серктеный ключ ЦА должен находится только на самом ЦА, он требуется только для выпуска новых клиентских сертификатов. В остальных случаях используется только сертификат ЦА, который можно свободно распространять. Аналогично и секретные ключи сервера/клиента - они должны находиться только у владельца ключа.

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

Если же у вас только подсеть, то используйте ответ Andrey Barbolin

Предлагаемый POSIX вариант это join. Если не устраивает, то вы сами можете конструировать проверку завершения потоков теми средствами какие вам удобно и какие доступны.

Самое простое: выставляйте в потоке атомарный флаг завершения, в основном потоке проверяйте.
Если можно подождать какое-то время, то можно использовать условную переменную с таймером, а не флаг.
Можно и очередь, но, по моему, это как из пушки по воробьям. Для этой задачи не совсем то. С тем же успехом можно использовать pipe. Но зачем, когда это можно сделать проще.

Имейте ввиду, что join все равно надо вызвать, когда удостоверитесь, что поток завершен. Чтоб окончательно освободить все ресурсы потока. Или надо заранее делать поток отсоединенным (detach). Я бы использовал join, а не detach.

У астры неплохая вики, а так же есть форум, пользуйтесь. Там уже большая часть вопросов "от новичков" разжевана.
На счет репозиториев, на сколько помню, там по умолчанию прописан только репозиторий лежащий на диске (на CD или на образе), никаких репозиториев в интернете не зарегистрировано. Если диск не вставлен или образ не смонтирован, то репозиторий будет не найден.
Но это можно легко поправить: https://wiki.astralinux.ru/pages/viewpage.action?p...

Дистрибутив Linux - это такой конструктор из нескольких достаточно глобальных вещей, которые могут меняться от дистрибутива к дистрибутиву, но их не так много и количество комбинаций не то что бы сильно велико. Но т.к. это конструктор, то общей "всебъемлющей" документации нет (кроме страниц ман, по понятным причинам) - в этот конструктор входит ПО, которое делают разные люди, часто никак не связанные с теми кто выпускает конкретный дистрибутив.
То что объединяет все дистрибутивы - это ядро линукс и набор "стандартных" утилит. По утилитам подойдут любые книжки по администрированию линукс. Про ядро то же можно что-нибудь найти, если вы программист.

То что отличает дистрибутивы один от другого:
1. пакетный менеджер: отвечает за установку и обновление софта, а так же за обновление всей ОС
2. системный менеджер: чаще всего сейчас это systemd, но есть и альтернативы, он отвечает за старт ОС, за запуск служб и т.п.
3. GUI - графических оболочек довольно много, хотя часто ноги растут из гнома или кед, каждый дистрибутив пытается добавить что-то свое отличительно в GUI оболочку, чтоб его можно было узнавать на фоне других. Но именно этот аспект ОС по большому счету не сильно важен - управлять ОС, в т.ч. и GUI можно из командной строки. Сейчас в GUI уже есть довольно много инструментов для управления ОС, но далеко не все.

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

Так что изучать нужно конкретный пакетный менеджер, конкретный системный менеджер, конкретную графическую оболочку, которые используются в конкретном дистрибутиве по документации на их сайтах. А так же стандартный набор утилит и стандартные правила работы Linux, которые едины для всех дистрибутивов и по ним есть книги.

Проблема, видимо, в том, что при подключении ВПН клиента шлюзом по умолчанию становится ВПН-сервер, к которому подключается ВПН клиент. Нужно убрать это поведение (опция push "redirect-gateway def1" в конфиге ВПН сервера 10.36.0.1).
В целом, не вижу проблем, что бы клиент и сервер работали параллельно на одном компе, если они оба не будут трогать настройки шлюза по умолчанию. Скорее всего для правильной маршрутизации трафика придется добавлять статические маршруты или прописывать правила фаервола, перенаправляющие определенный трафик в нужный интерфейс.

Вам нужно на роутере добавить маршрут до сети 192.168.5.0/24 через IP eth0.
На самом компе добавлять маршрут не нужно, т.к. он имеет IP адреса во всех задействованных сетях, то маршруты уже есть.
Пингами с роутера проверяете доступность IP eth1.
Т.к. eth2 работает мимо ОС, то схема должна работать.
Естественно на компе надо включить маршрутизацию пакетов и настроить/выключить фаервол.
Сниффером слушаете eth1.

Более "чистая" и точно рабочая схема была бы, если использовать второй ПК: eth2<=>второй ПК<=>router
На втором ПК можно настраивать сниффер и видеть весь трафик.

В скрипте после создания ссылки измените ее владельца с помощью chown.

Через файл - это самый простой вариант.
Более технологичный вариант - запускать процесс с перенаправлением потоков stdin/stdout/stderr в каналы (pipe).
В этом случае можно в режиме "on-line" получать вывод от запущенного приложения и генерировать вход для приложения. Этот сложнее, но дает гораздо больше гибкости в работе с запускаемым процессом.

Принцип тот же, только, обычно, зависимые библиотеки не таскаются вместе с программой, а устанавливаются как зависимости в общие каталоги (/usr/lib и т.п.).
Создается пакет для используемого в конкретном дистрибутиве пакетного менеджера, по правилам этого пакетного менеджера. В пакете описываются зависимости и при установке вашего софта, зависимости так же будут установлены, если, конечно, они существуют как пакеты в репозиториях дистрибутива.
Для своего софта можно сделать и поддерживать собственный репозиторий, который можно добавить в пакетный менеджер, или добиться включения в родной репозиторий дистрибутива, или распространять пакет каким-то другим образом (его можно поставить в ручном режиме с помощью того же пакетного менеджера, указав файл пакета).
Так же возможно распространять ПО в исходниках и пусть каждый желающий сам собирает, в readme описать все зависимости и как их установить в наиболее популярные дистрибутивы. Кстати в исходниках вместе со сборкой софта, вполне возможно сразу собирать пакет для используемого пакетного менеджера. В установке с помощью пакетного менеджера есть преимущества перед установкой с помощью make && make install