![OLORG[dot]ru](http://olorg.ru/application/maxsite/templates/olorgru/assets/images/logos/olorg-logo.png "OLORG[dot]ru"){kind=logo}
Сегодня хочу поделиться небольшим рецептом в организации личного облачного хранилища. Когда-то давно смотрел в сторону OwnCloud, но страсти по нему подутихли и повился развивающийся форк под названием NexCloud. Да и само позиционирование названия прям таки кричит, что это что-то новое и революционное. Если и Вам этот процесс интересен, то за сим творением и рецептом, прошу под кат.
Вот и свершилось в моей домашней лаборатории, когда имеющегося диска внутренего диска перестало хватать, и для тестирования новых проектов пришлось подключать внешний диск к ESXi хосту как DataStore.
Если с налета подключить USB диск, то его можно будет только прокинуть только в гостевую ОС, а дальше через подключать как NFS или как iSCSI, что быстродействия, увы, не добавит. Это все происходит, так как работает служба usbarbitrator, которая знамиется перенаправлением USB устройств в гостевые системы. Если Вы не используете эту службу, то есть уже решение обозначеной этой проблемы.
В предыдущей статье я рассказывал, как я установил PowerShell на Linux хост (без гуев и прочего), а вот сегодня хочу рассказать как писать и отлаживать код на удалененом сервере.
В Windws для локального написания и отладки кода имеется стандартный и отличный инструмент PowerShell ISE, а вот с удаленным linux хостом, до которого у тебя есть только shh (считай голая консоль) особо не разгуляешься с ISE. Но у Microsoft и на это есть рецепт - Visual Studio Code, о нем как раз дальше и пойдет речь.
Сегодня мы имеем большой тренд на универсальные приложения, которые могут исполняться в любой среде и на любой ОС. Если вы регулярно следите за небольшим колиством статей на моей сайте, то должны знать, что я немного Гик и извращенец, в хорошем, как мне кажется, смысле этих слов. Да я у себя дома на постоянной основе держу гипервизор VmWare ESXi, нпа котором в постоянно крутится около 10 машин, на одной из которых работает и этот сайт.
Так вот поступила мне домашняя задаца по автоматизации получения актуальных файлов с удаленного сервера, а этот удаленный сервер не всегда может быть в онлайне, ну или не всегда отдавтаь мне актуальные файлы.
Что сделал я? - Поднял аиртуалку с Windows и по быстрому написал скрипт на PowerShell для скачки проверки и актуализации этих файлов. Далее убедися в том, что скрипт мой работает, но как-то держать для этого хоть и маленькую виртуалку на Windows как-то расточительно, русурсов Widows всетаки хорошо кушает для моего маленького ESXi сервера. Было решено переводить все это она Linux, а мой любимай дистрибутив - Debian в минимальном установочном комплекте.
Чуть больше года назад я писал сатью Бесплатный SSL сертификат для ESXi хоста, в которой я возносил к богам ZeroSSL, но время показало, что и тут припрятана ложка дегтя. В итоге спустя год, при выпуске очередного сертификата я получил сообщение "You have reached the maximum amount of 90-day certificates allowed on the Free Plan." 
. Ах тыж зара то такая. По началу я игнорировал просроченный сертификат на своем ESXi сервере, а вот когда Web морда перестала нормально открываться в Google Chrome терпение начинало заканчиваться, тут мне на телефоне от Google пришла в рекомендации статья с Habrа, про ACME протокол, в котрой было описано большое существование клиентов (кроме certbot), которые можно использовать для Let's Encrypt и других сервисов поддерживающих этот протокол.
Глаз мой упал на 2 клиента win-acme и Posh-ACME (первый вроде как бинарный, а второй это скрипты на PowerShell), из плюсов это ввсе можно выполнять на Windows, от первого я ожидал GUI, но видимо не судьба, токо консоль.
Привет, мой дорогой друг 
. Сегодня хочу рассказать как использовать nginx как реверс прокси, не для веба.
Суть в том, что мне нужно было забалансировать и затащить группу публичных сервисов, под удобное и легко запоминающееся имя.
Первым делом для теста был быстренько поднят локальный актуальный Deban и на него водружен nginx, а затем пошли эксперементы с проксированием TCP.
Бегло изучив документацию стало понятно, что нужно использовать директивы stream и upstream nginxа.
Стоит отметить, что директиву stream нужно использовать отдельно от стандартной http, поэтому в директории /etc/nginx/ создадим новую директорию application, для использования проксирования приложений, и а самый конец файла конфигурации /etc/nginx/nginx.conf добавим возможность импорта application конфигураций из нового каталога указав строку "include /etc/nginx/application/*.conf;".
Как-то в моей маленькой домашней локальной лаборатории потребовалось изолированной сети, в которой присутствуют только виртуальные машины только с адаптерами внутреней сети, дать доступ в Интернет, не добавляя адаптеров типа NAT. Сказано - сделано.
Все действия я провожу с машинами в VirtualBox. Мне потребуется создать еще 1 машину - роутер, которая будет являться шлюзом для других VM и будет предоставлять доступ в Интернет.
В качестве роутера будет выступать виртуальная машинка на борту у которой минимальный Debian.
Создаем новую виртуальку, для которой назначаем 2 сетевых интерфейса первый тип подключения NAT, а второй с типом подключения внутренняя сеть.
Следующим этопом, на котором я не буду останавливаться - установка Debian. А дальше переходим к настройка сети.
