3vi1_0n3

Могу посмотреть, но не обещаю, что быстро

1) Ставим один сервак с терминалами, но хороший, надежный, отказоустойчивый.
2) Делаем удаленный доступ на этот сервер для рабочих мест, рабочие места можно сделать бездисковыми терминалами
3) Непонятно, что должны делать клиенты с клиентскими компьютерами. Если просто в интернет выходить - то одно, если с сетью хостела связаны, там заказ на обед сделать, то другое.
4) Непонятно, зачем ноуты
5) Непонятно, зачем офис 365
6) Знаю хорошего производителя софта для гостиниц, могу порекомендовать
В общем, надо как-то упрощать систему, а не наоборот. Если дадите детали, можно спроектировать оптимальный вариант. И более конкретную информацию, по общей информации вариантов слишком много.

Ну, в общем, не такая уж это страшная вещь. Можно так:
apt-get autoremove
Потом посмотреть, настройки каких пакетов остались:
dpkg -l | grep ^rc
И их можно потом удалить путем dpkg --purge или apt-get remove --purge
Можете воспользоваться еще deborphan
Или вот даже так:

dpkg -l | grep ^rc | awk '{printf $2}' | xargs dpkg --purge

Разве что вот так:
=IMPORTRANGE("ключ-документа", "Лист1!A2:A12")
Ключ документа берется из урла (https://docs.google.com/spreadsheets/d/ключ)

Если не ошибаюсь, в файле ~/.config/mc/ini надо поменять строчку
copymove_persistent_attr=1
и перезапустить mc

SSH-клиент умеет выполнять команды удаленно.
Для этого:
1) Надо настроить аутентификацию по ключам, либо использовать askpass (не очень хороший вариант)
2) Использовать команду
ssh user@host команда-для-удаленного-хоста
Или сразу записать в переменную результат:

RESULT=$(ssh user@host команда-для-удаленного-хоста)

Либо chmod +x filename, либо "sh script.sh"
Просто так на выполнение без права на выполнение файл запустить нельзя.

1) Включить AllowOverride
2) Цитата с httpd.apache.org/docs/current/howto/htaccess.html:

There are two main reasons to avoid the use of .htaccess files.

The first of these is performance. When AllowOverride is set to allow the use of .htaccess files, httpd will look in every directory for .htaccess files. Thus, permitting .htaccess files causes a performance hit, whether or not you actually even use them! Also, the .htaccess file is loaded every time a document is requested.

Further note that httpd must look for .htaccess files in all higher-level directories, in order to have a full complement of directives that it must apply. (See section on how directives are applied.) Thus, if a file is requested out of a directory /www/htdocs/example, httpd must look for the following files:

/.htaccess
/www/.htaccess
/www/htdocs/.htaccess
/www/htdocs/example/.htaccess
And so, for each file access out of that directory, there are 4 additional file-system accesses, even if none of those files are present. (Note that this would only be the case if .htaccess files were enabled for /, which is not usually the case.)

Там же говорится о том, чтобы избегать по мере возможности использования .htaccess и использовать

Ошибка 400 обычно возникает при ошибке ssl, например, при попытке идти по http на https и наоборот, при ошибке установки защищенного соединения. Как избавиться зависит от того, что именно происходит. Возможно, редирект с https на http решит вопрос.

Серверный сертификат может быть подписан кем угодно, на использование клиентских это никак не влияет, их можете подписывать своим CA, главное серверу указать потом его, чтобы клиентские считались валидными. Вот тут можно пример посмотреть, например. При использовании mutual аутентификации при помощи сертификатов может, конечно, возникнуть вопрос, если клиент не знает корневого сертификата, которым подписан серверный.

Оказывается были хот-линки на картинки с моего сайта
Решил следующим образом: в конфиге nginx'а написал

if ($http_referer ~* (http://адрес-сайта-личера)) { 
        return 301 "http://хостинг-картинок.ru/img/some.png";
    }

В файле png картинка со ссылкой на мой сайт. Мелочь, может быть, но меня пока устроит.

Как-то так