Tech

По той же причине, что и делают совстенное облачное хранилище

В простых кейсах с малым количеством телефонов - смысла не имеет.
Когда у тебя сложный "вариант" с разными переадресациями, уведомлениями итд, то уже требуется свое. Или когда нужна интеграция с софтом, которого нет у облачного провайдера.

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

которая гораздо удобнее и легче в настройке

Ровно до тех пор, пока у вас не появляются нестандартные запросы. Например, перевод входящего звонка в зависимости от графика работы подразделений, меняющегося по праздникам и выходным. Или использование нескольких очередей с самостоятельной регистрацией в них операторов и интерфейсом, отображающим отвеченные и пропущенные звонки в этой очереди. Или дать возможность регистрироваться под одним номером с нескольких телефонов (рабочий аппарат сотрудника, софтфон на смартфоне сотрудника, софтфон на домашнем компьютере сотрудника). Или связать напрямую свой Asterisk с Asterisk организации-партнёра/клиента для прямых звонков.
Чистый Asterisk очень гибок в настройке, способен работать напрямую с базами данных, LDAP/AD и запускать внешние скрипты.

да - ищите "rainbow table generator". И можно прямо готовые радужные таблицы скачать

Есть. Называется python + модуль itertools.

import itertools
import string

def generate_strings(length):
    chars = string.ascii_letters + string.digits
    for item in itertools.product(chars, repeat=length):
        yield "".join(item)

for string in generate_strings(3):
    print(string)

Для 8 символов поменяйте 3 в коде на 8.

Новые настройки таймаутов будут применяться только к новым RDP сеансам, текущие сеансы придется завершать вручную

It depends :)

То есть здесь у каждого свое собственное мнение. Кто-то счтает, что достаточно бесплатного LE, кому-то хватает платного DV. OV нужно тогда, когда без него никак нельзя - например для эксча, когда нужно в один сертификат засунуть четыре-шесть разных имен (то есть два-три домена). EV я даже не знаю, когда он и зачем, но раз есть - значит востребован.

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

Объясните, плиз, в двух словах

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

Основная задача, чтобы на гитхабе был основной репозиторий

Все репозитории на самом деле равноправны и вы можете любой из них объявить «главным», если хочется. Это вообще не важно.

На остальных компах такие же настройки сделать?

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

Или сделать на каждом компе имя типа MyName_COMP1?

Вы хотите сохранять информацию о том, на каком компе создан коммит? Что это вам даст?

для компов репозиторий на гитхабе является remote или origin?

Репозиторий с которым вы работаете на текущем компе, является локальным. Все остальные по отношению к нему будут называться внешними (или удаленными, по-английски — remote). Ссылку на внешний репозиторий обычно запоминают в специальной переменной. Как правило используется связь с одним внешним репозиторием и принято называть эту remote-переменную origin. Но это имя может быть абсолютно любым, особенно если внешних репозиториев подключено несколько. Например вы можете вообще не использовать гитхаб, а обмениваться коммитами между компами напрямую. Ваш локальный репозиторий на одном компе станет внешним для другого репозитория на соседнем компе. Всё относительно.

Корень сайта непонятно зачем бэкапить, если весь код и так в репозитории.
Mysql по живому можно бэкапить c помощью специальных утилит, таких как Percona XtraBackup

Делают read-only реплику и бэкапят её обычным способом.

User - это пользователь, т.е. человек или разработчик, а не ПК. Используйте стандартный подход Github flow: https://habr.com/ru/articles/346066/

Предполагаю, что можно сделать его зашифрованным через openssl и именно его синхронизировать или даже версионировать через git (или оставить текущую схему с ансибл). При входе в систему расшифровывать его, кладя в RAM и подключать через "source .bashrc". Работать. После окончания рабочего дня расшифрованный файл надо удалить (ну или изначально при начале работы класть его в RAM).
Но в этот файл регулярно вносятся изменения, бывает раз в день, а бывает лишь один раз в месяц.

Не самый плохой вариант шифровать через openssl.
Только зачем расшифровывать файл? Расшифровывайте прямо в память во время использования

то есть в .bashrc можно например так

dbuser=database_user
dbpass="$(openssl enc -d -base64 -aes-128-ctr -nopad -k secret_key.txt<<<"l1k2j3kl14jjkl321h4lk124123;ljk2`13jlkj")"

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

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

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

https://project-awesome.org/webpro/awesome-dotfiles

Нет, 499 код не является стандартным кодом http (а является специфическим для nginx) и не влияет на seo.

Да. Можно.

Так же подтверждаешь права на доступ к сайту (dns, файл на сервере, код в хтмл). Пробовал сам.

Не сломаешь, если не будешь удалять верификационные данные владельца.

Ссылки все разные (то что после goto).

Убирать эту дыру и для не легитимных редиректов отдавать 403.

Если открыть в браузере этот auth.php то станете админом, соответственно можно закинуть на сайт любые файлы и делать в админке что угодно.

plolog_before.php это системный файл битрикс, если кратко, его включение делает возможным использовать функции из ядра Битрикс.

Включить впн, если ресурс в блокировке.
Для того чтобы была скорость - можно сделать себе личный впн сервер. Я думал в этом году они уже у всех есть, ибо без впн половина инета не работает)

IP камеры регистраторы Hiwatch (Hikvision) или imou (dahua) главно одного бренда.
Хороший, желательно двухдисковый регистратор в сеть с камерами для архивирования видео - на него заводим первые потоки камер (те что 2+мпикс)
Самый дешевый регистратор на достаточное кол-во каналов к телевизору - на него заводим вторые потоки камер (разрешение 320-480)
Такая конфа будет в разы дешевле и стабильней вариантов с компами, ivms и тп.