RDP Wrapper

 Есть не безизвестный хак для удалённого подключения, ну и пара форков, которые определяются как трояны. Проверять трояны это или нет не особо хочется, тем более тратить на это время. Есть параверсий и по мнению автора всё зависит от одной иньки. Ок, опустим кучу проблем и возможных решений, в общем мне подошёл такой рецепт:
Releases · stascorp/rdpwrap · GitHub

ну и собственно инька

https://raw.githubusercontent.com/sebaxakerhtc/rdpwrap.ini/master/rdpwrap.ini

после ребута всё заработало.

ЗЫ

если после удаления враппера не старнует удалённый стол - фиксим через реестр:
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TermService\Parameters
ServiceDll должен иметь значение %SystemRoot%\System32\termsrv.dll

Дичь, которой быть не должно. Подключаем клиентов к компьютерам с одинаковыми именами через один айпи.

Дано:

- жменя серверов с одинаковыми именами (srv)

- основной домен с местным админом

- один влан

- одна подсеть

Найти:

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

И так решение:

1) создаём AD и цепляем к нему сервак с именем, получаем fqdn типа srv.dom1.local

2) создаём на стороне основной ad TSG, создаём отношение между доменами (2 way local, тут, к сожалению это важно)

3) добавляем группы админов из основного домена в "соседний", в группы локальных админов (GPO Group mapping или руками)

4) добавляем srv.dom1.local в оснастку на BROKER (в нашем случае можно всё в 1 хранить, всё равно больше 10 серверов не получится запихнуть)

5) накидываем роль хост сервера, создаём коллекцию и правила безопасности

6) настраиваем haproxy, который на стороне белого айпи и имеет доступ к нашей подсети

В данном описании будет работать до 10 серверов на 1 деплойменте шлюза треминалов, поэтмоу плодить их отдельно не вижу смысла.

Из проблем:

1) пока не ясна причина дропов коннекта на haproxy

2) web app либо gateway придётся разносить по портам, например оставить на 443м web apps а сам tsg спрятать, например за 445

Apache dynamic proxy beckend

 Название немного кликбейтовое, но задача была такова:
 - проксирова контент с сервера за фронтом по передаче имени в url, например: запросы на wss://frontend.local/console/backend1.local/ticket/dynamic-ticketid должны попадать на wss://backend1.local:443/ticket/dynamic-ticketid. Всё бы ничего, но для сайтов как на стороне фронтенда так и на беке есть свои реврайты и они не должны пострадать. Решается подобная задачка при помощи директивы ProxyPassMatch.

ProxyPassMatch "^/console/(.*)/ticket/(.*)$" "wss://$1.local:443/ticket/$2"

В случае с необходимости в обратном прокси вопрос можно решить тоже:

ProxyPassMatch "^/console/(.*).local/(.*)$" "https://$1.local/$2"

ProxyPassReverse "^/console/(.*).local/(.*)$" "https://$1.local/$2"

Не забываем, что если у нас на backend используется ssl - то желательно ещё об этом упомянуть в конфиге и, по необходимости, отключить проверку сертификата того же backend:

    SSLProxyEngine on
    SSLProxyVerify none
    SSLProxyCheckPeerCN off
    SSLProxyCheckPeerName off
    SSLProxyCheckPeerExpire off

Dameware, рабта в нескольких доменах

    Тут речь пойдёт об использовании Global Host List в разных доменах. Проблема изначально сотоит в том, что Dameware использует NETBIOS имена компьютеров для подключения, чего нам мало для работы с несколькими доменами, нужен fqdn. Поэтому пришлось сделать несколько движений для каждого домена что бы не переименовывать руками каждый компьютер.

    И так нам понадобится: Dameware Central Server, Remote Support (куда без него) и собственно кучка доменов с двусторонними локальными отношениями (на External не тестировалось).

    Далее, подключаемся к серверу, заходим в Global Host List, создаём папку, (можно и без неё обойтись, но поверьте с ними проще), я использовал имя домена в качестве папки, далее импорт из AD, используем нужное имя домена, пользователь, группу компьютеров. В общем после импорта получаем списк нужных нам компьютеров/серверов. Далее делаем экспорт из папки в файл, удаляем все компьютеры из папки и редактируем файл. Т.к. у нас обычный *.xml - то замена в любимом редакторе будет весьма проста: меняем </HostName> на .domain.local</HostName> по всему документу, сохраняем и импортирум этот же файл обратно. ТАким образом у нас вместо основного имени для подключения теперь fqdn, чего вполне достаточно для работы далее.

Asterisk приоритеты, FIFO & LIFO.

 Случилась задача:
Расперделить приоритетность звонящих на тех кто должен быть первым, и тех, кто звонил не 1 раз и общался с оператором, и всех остальных. По сути обратная логика VIP номеров. задача интересная, не совсем сложная. Решается кастом контекстом, завёрнутым на скрипт со статусом, если статус 1 - то абонент падает в приоритете. Но при переносе на прод - оказалось, что каждый последующий звонящий оказывался первым. С точки зрения приоритета мало чт оизменилось, а вот вся логика оказалась неверной с точностью до наоборот, конечно же это всех не устраивало. Что делать, куда копать - я не знал и по сути не знал бы, если бы мне не подсказали 2 ключевых слова: FIFO & LIFO. Оказалось, что бы развернуть очереди на астериске - достаточно указать 1 переменную в файле globals_custom.conf

QGOSUB=subQueueAlert,s,1

Если переменная дальше нужна, а очередь нужно сохранить - удаляем ,s,1, сохраняем, перечитываем конфиг и радуемся жизни.

Veeam B&R восстанавливаем работу после критической ошибки.

И так, прошлая статья показала, что не стоит делать с ВМ, особенно если вы там организовали хранилище, пусть даже и бекапов (особенно). Далее я получил следующие ошибки:
"Error: Cannot proceed with the job: existing backup meta file 'Germany-Folder.vbm' on repository 'Germany' is not synchronized with the DB. To resolve this, run repository rescan"

Рескан естественно не проходил, потому что бекапы уже туда сложены (по базе данных), а файл .vbm старой версии. Можно было попробовать отредактировать базу данных, но я крайне не рекомендую этого делать. ПОэтому решаем делать так:
удаляем файлы *.vbm со всех папок на уроненом датасторе, затем заходим в репозитории, находим наш репозиторий, проходим рескан заново. После рескана пробуем запустить джоб - не получается, снова ошибка:

Processing SOME_VM_NAME Error: All instances of the storage metadata are corrupted. Failed to open storage for read access. Storage: [\\path\to\Jobe\name\JOB-NAME2020-08-16T011455_0F5C.vib]. Failed to download disk. Shared memory connection was closed. Failed to upload disk. Agent failed to process method {DataTransfer.SyncDisk}.      01:42

Что бы решить эту пробелму идём в Home\Backups\Disk, ПКМ по нашему джобу и  Remove from configuration, длее перезапускаем джоб и радуемся уже успешному бекапу. По восстановлению более старых точек просто скажу так, есть копия, кототрая находится на другом хранилище, поэтому данными файлами я могу немного принебречь.

Vmware: почему ручные снэпшоты это плохо.

 Очень редко я пишу, особенно сюда. Но, надеюсь мне будет напоминалка или Вам руководство, ка кделать не надо. Предыстория: есть несколько нод, собранных одним vcentrom разнесены ноды по разным странам: Израиль и Германя. Бекап производится 1 бекап сервером на raid массив на самом бекап сервере (Израиль), копия на файловой windows шаре (Германия). Бекапы с серверов в Германии складываются на шару в Германии и копии летят в Израиль. В какой-то момент было необходимо по какой-то космической причине кому-то (возможно даже мне) сделать снимок на виртуалке с файловой шарой в Германии, которой под thin provision было выдано 4 Tb жёсткого диска из 5.5 возможных. Там же вертелось ещё пара виртуалок. Получив утром сообщение о том, что есть снапшот, который кто-то забыл удалить я решил попробовать это сделать по привычке, прямо из консоли, но не тут то было, удаяться он не особо хотел, ушло на это больше, чем планировалось (больше рабочего дня). На следующий день по понятным причинам не прошли некоторые бекапы и не удалился снепшот, зато появилось сообщение о том, что нужно консолидировать диски.
Пфф, думал я. А зря, консолидация не проходила, т.к. место закончилось, мало того, из-за thin provision ушатался ещё и виртуальный роутер, благодаря которому была построена часть инфраструктуры, вертелся он там же на том же разделе. Ок, если мы не можем совместить данные, давайте попробуем их вырезать (удалить, потерять, как хотите). Тушим машину, удаляем из инвентаря диск на машине (не физически), далее идём по ссх на хост и пробуем переименовать VM_Name_2-000001-sesparse.vmdk, запустить машину, (если удалить или переименовать его не удаляя диска с ВМ - ВМ не запустится!). Машина стартонула, диска вроде нет, ок, теперь вручную добавляем существующий диск - получилось. Заходим в машине в диск менеджмент и делаем снова диск онлайн - получилось. Теперь проверяем диск (можно даже онлайн) - прошло успешно за пару сек - прекрасно. Теперь смотрим на дату измененя файлов .vmdk, интересует наш (в конкретном случае VM_Name_2-flat.vmdk - дата стоит сегодня и время почти актуальное, только теперь можно удалить переименованный VM_Name_2-000001-sesparse.vmdk.bak, освободив при этом достаточно места что бы жить дальше. А дальше предстояло восттановить работу бекапов...