khacsam

ip-KVM не уверен, что FullHD на 60гц хотя бы потянет. Для этой технологии ниша вот совсем другая.
А вы в игры на них играть собираетесь. Так он еще и задержку даст как ни крути.
USB--IP-- USB для клавы-мышки и video--ip--video для видео...+ еще звук..
Не, пасьянс разложить или в шахматы поиграть можно будет, но вот что-то динамичное и тяжеловесное врядли.
Вы картинку будете видеть с задержкой, и звук, и управление с задержкой...

Смешались в кучу кони.. Каким образом резервная копия поможет ускорить перенос/переезд? Никаким.

Если интересует безотказность, но нужно иметь как минимуму два сервера в разных ДЦ (и лучше в разных странах) и смотреть в сторону балансировщика нагрузки. (И, естественно, моментальной синхронизацией данных).

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

AnyDesk - лучшая. Ставим на командировачные ноуты и удаленщикам не один год.
Для некоммерческого использования бесплатна )))

Здесь можно найти общие моменты.

Если поподробнее, то порекомендовал бы книги (лучше в порядке их следования):
1. Чистая архитектура
2. Высоконагруженные приложения
3. Шаблоны проектирования для облачной среды (если нужно углубиться в микросервисы и немного познакомиться с kubernates)
4. Совершенный софт (тут и про архитектуру и про управление проектами)
5. Проектирование событийно-ориентированных систем (здесь про паттерны работы с kafka, о самой kafka нужно в других книгах искать)

Это конечно не ответ на вопрос - но:
Вместо того чтобы делать образ просто загрузить все установленные программы и образы в MDT. Он как раз и позволяет сразу вводить ПК в домен.
https://habr.com/ru/post/442834/

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

lastUserSuffix=$(cat /etc/passwd | awk 'BEGIN {FS=":"}; {print $1}' | grep systemd | sort -n | sed 's/systemd-//' | tail -1)

Я тут ищу пользователей с именем systemd-***, думаю вам не составит труда изменить пример для своих целей.

iRedMail из коробки работает - можно на Ubuntu поставить, MX записи прописать, fail2ban и SSH настроить.

Начните с SSI (Server Side Includes) — гуглите.
Пример для вас. Файлы должны быть в html, но с расширением .shtml:

1. Создаём основной файл и файлы шапки и подвала. Например, index.shtml, header.shtml, footer.shtml.

2. В основном файле прямо внутри html-вёрстки пишем:
<!--#include file="header.shtml"-->
...и туда будет вставляться содержимое файла шапки.

3. Там же внизу:
<!--#include file="footer.shtml"-->
...и туда будет вставляться содержимое файла подвальчика.

По крайней мере, для тренировки на простых учебных сайтах — самое то.
Смертельно быстро и никакого программирования )

Удачи!

1. Никаких «вечных серверов». Даже как-то неловко разъяснять такое. «Вечный сервер» — маркетинговый ход, фактически мошенничество, который закончится, как только компания изменит условия/реорганизуется/закроется. Следует читать как «ну, проработает года три, а далее — неизвестно».

2. Непонятно, какого рода у вас информация, и что именно вы понимаете под словом «захостить», также непонятен критерий автономности. Разместить информацию в публичный доступ? Должна ли она индексироваться? Нужен ли для неё контроль доступа? По какому протоколу она должна быть доступна? Она будет нужна только вам через 10 лет, или кому-то еще? Это лицензированный контент, который могут удалить по DMCA (фильмы, сериалы, музыка)? Это персональные данные (сливы баз данных)? Информация популярна и/или востребована на данный момент? Есть вероятность, что она будет сравнительно востребована через 10 лет? Информация каталогизирована? Информация тематическая (например, архив, посвященный конкретной теме, области науки и т.п.)? Важно ли удобство и скорость доступа к информации?
Технологий много, но они все разные, с разными назначениями. Ответы на перечисленные вопросы необходимы, чтобы отбросить неподходящие и подробно рассмотреть подходящие.

3. Если информация публична и востребована, и будет востребована через 10 лет, то следует использовать DC++, BitTorrent + веб-хранилища с прямыми ссылками на файл, добавив ссылки в .torrent-файл, в виде webseed.
Bittorrent существует с 2006 года, популярен, клиенты есть под все ОС, совместимость и надёжность отличные.
DC++ всё еще имеет популярность. Основное преимущество перед Bittorrent: возможность поиска файла по его имени или названию директории, возможность лёгкого обновления и дополнения информации (нет привязки к «каталогу» в виде .torrent-файла)

Если информация конфиденциальна или требует контроля доступа, и у вас и кого-либо другого не будет возможности как-либо поддерживать её в течение 10 лет (я не знаю вашу ситуацию, поэтому предположим, что вам грозит 10-летний тюремный срок), то, возможно, есть смысл оплатить облачное хранилище от крупных компаний (Google, Yandex, Microsoft, Apple) на 10 лет вперед. Это не даёт никаких гарантий, но считаю такой вариант более надёжным, нежели хостинг общего плана (и особенно VPS).

Если информации немного, она не защищена авторскими правами, каталогизирована и полезна, можно банально разместить её на давно существующих бесплатных хостингах, вроде Ucoz, Google Sites, Neocities, загрузить на Bitbucket, Github, Sourceforge (последний поддерживает хранение больших файлов, которые можно скачать по прямой ссылке, вполне подойдёт в качестве webseed для торрента, к слову).

Если не боитесь попробовать развивающиеся, но еще не устоявшиеся технологии, присмотритесь к IPFS. Он работает по принципу Bittorrent, но позволяет получать доступ к информации через HTTP, а также поддерживается крупными игроками в лице Cloudflare, у которой есть шлюз из интернета в IPFS: https://cloudflare-ipfs.com/
Я держу несколько статичных сайтов с собственными доменами в IPFS, на домашнем компьютере, за шлюзом Cloudflare. Преимущества: все плюсы BitTorrent, возможность доступа как к сайту (в т.ч. на своём домене), индексация поисковиками, есть сервисы по долгосрочному платному хранению файлов (eternum.io, pinata.cloud), возможность лёгкого обновления информации. Недостатки: работает всё ещё достаточно медленно и нестабильно, только статичные сайты.

4. Судя по вашему комментарию выше, у вас всего 100 ГБ медиафайлов. Это вообще ерунда. Если они публичны и представляют ценность хотя бы для узкого круга людей, можете захостить их у меня, через проект Schare: https://valdikss.org.ru/schare/
Мой критерий автономности — максимальная независимость от сторонней инфраструктуры, поэтому файлы хостятся на домашнем сервере, а раздаются в сетях децентрализованного файлообмена.

Выгодно ли содержать домашний сервер?

Мне -выгодно.
А выгодно ли вам - это у вас надо спросить.

Насколько затратно, имея в виду затраты на электроэнергию при стоимости 1.81р/КВт содержать сие чудо

100-150рублей в месяц.

и имеет ли оно какую либо выгоду либо смысл?

Да кто же знает кроме вас, что для вас выгодно?

Либо я зря заморочился и аренда VDS была бы выгоднее?

Ну так сравните и подсчитайте.

Потому что под вайлом

Вот накидал блики, при желании можно раскачать до вполне приемлемого состояния https://jsfiddle.net/l2banners/tjm7p1r6/4/

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

Я перед собеседованием на должность sql-джуна будучи полным нулем за ночь порешал задачки на этом сайте и на следующий день решил все предложенные задачи и был принят) Скажу так - я бы посоветовал порешать эти задачи, они там предлагаются по нарастанию сложности и подкреплены теорией, за которой вам не нужно лишний раз лезть в учебники. Уверяю, с каждым десятком решенных задач Вы будете чувствовать себя гуру sql) Спустя задачек 30, когда у Вас сформируется представление о том, что из себя представляет SQL на деле, тогда можно приступать к литературе, поверьте, после практики гораздо легче воспринимать материал, ибо уже имеется представление, о чем речь.
По литературе(с небольшими пояснениями):

1. Введение в системы баз данных(Автор C.J.Date) - на мой взгляд очень доступное и максимально компактное описание того, на чем базируется SQL, разжеваны основные понятия, рассмотрены нормальные формы, а после предлагаются задачки.

2. SQL Полное руководство - тут понятно по названию, здесь можно найти описание всех возможностей. Ищите наиболее позднее издание(у меня третье, для примера, это 2015 год).

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

Если вы выбрали MS SQL Server:

1. Microsoft SQL Server 2012 Руководство для начинающих - там хоть и не сильно углубляясь, но описано почти все что нужно на начальных этапах. Там и про индексы, и про оптимизацию, и про бизнес-аналитику, в общем, рекомендую.

2. Microsoft SQL Server 2012 Создание запросов - просто и исчерпывающе(на момент издания) о том, как можно и нужно писать запросы на t-sql(расширение sql для MS SQL Server) с закреплением материала предлагаемыми заданиями.

Если Вы выбрали Postgresql, то официальное руководство там исчерпывающее.

По Oracle и MySQL советов дать не могу, ибо дела не имел. Удачи!

Книги это, конечно, здорово, но как показывает практика, большинство книги либо забрасывает, либо просто читает и не особо новые знания впитывает. (если речь о начинающих разработчиках, которые прям с нуля начинают книгу читать)

А самый логичный способ что-то изучить - это практика, практика и еще раз практика. Если нет реального проекта с реальными проблемами - рекомендовал бы пару ресурсов: sql-ex и pgexercises, там можно поработать как с совсем простыми и примитивными запросами, так и с гораздо более сложными.

Ну а овладев азами можно уже и книгу брать, чтобы закрыть пробелы, либо документацию по конкретной СУБД

> Я (как и руководство компании, в которой я работаю)
"Ни разу не технарь, но знаю лучше всех"

Тебе от компа требуется загрузка по сети и запуск RDP-клиента, а ты пытаешься сделать какую-то универсальную хрень для всего.
В офисе за глаза хватит тонкого клиента на линуксе в squashfs, который грузится по сети и запускает RDP-клиент.

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

Почитайте как сделать правильно REST API (для POST и не только).

• HASH - подпись с применением функций хеширования и формул конкатенации данных запроса.
  
• RANDOM - случайная строка символов или число для создания уникального запроса
  
• TIMESTAMP - контроль давности запроса на стороне сервера.
  

Кратко: нужно три дополнительных параметра (кроме параметров запроса к API): HASH, RANDOM, TIMESTAMP.
HASH - формируем по TOKEN'у (его мы получаем заранее от сервера) на основе всех данных, передаваемых при запросе к API: API-параметры, RANDOM и TIMESTAMP.
Проверяем подпись при получении запроса и сравниваем с HASH: если подпись равна HASH - исполняем запрос.
 

UPD: про домен (доп.вариант проверки):
Входные данные, которым мы хотим доверять:
1. Доменное имя клиента API: домен_ожидаемый
2. TXT-запись домена клиента API: TXT_запись_ожидаемая

Имеющиеся данные (при получении запроса к API от клиента):
3. IP клиента API: IP(1)

При инициализации новой сессии (перед формировании нового токена), можно делать 3-4 DNS-запроса к любому публичному DNS-серверу (перед непосредственной генерацией токена!):
1. reverse_lookup (IP(1) клиента API в имя домена(1)) => узнали домен(1).
2. lookup (домен(1) в IP(2) по A-записи) => узнали IP(2)
3. снова reverse_lookup (IP(2) в имя домена(2)).
4. По желанию: можно проверить наличие нужных TXT-записей (и любых других) и сравнить с ожидаемыми (т.н., "статический публичный токен").

После получения всех данных, проверяем:
Домен_ожидаемый===домен(1) && IP(1)===IP(2) && домен(1)===домен(2) && TXT_запись_ожидаемая===TXT_запись_полученная

Если выражение истинно, то выписываем токен на обратившийся клиентский IP для предоставления доступа этому клиенту для начала работы с нашим API.