Да, есть такая возможность. Я не говорил что это минус и все, можно восстановить даже и без bootstrap-а, имея не шифрованное хранилище. Но как показала практика намного «дешевле» как по времени так и по железу иметь копию каталога и бутстрапа на черный день, тогда «неявный минус» отпадает.
По Bacula уточню:
1. Резервное копирование на удаленный хост:
— Копирование идет на StorageDaemon, который может быть на любом компютере. Причем для разных типов бекапа можно использовать разные файлохранилища: для полных бекапов — один, для диф — другой, для 2х-недельныз — третий.
2. Шифрование
— Бакула умеет шифровать как хранимую информацию, хотя можно ее хранить и в том же трукрипте, так и передаваемую информацию. Но есть пара ньюансов. Первый — метаданые не шифруются (название файлов, пути, владелец… ), второе — восстановить при полной потере директора — use the force, Luke.
3. На одному клиенту может быть несколько одновременных задач которые будут писать на разные файлохранилища используя/неиспользуя сжатие и шифрование. Такое дает определенную гибкость и повышение производительности при копирование большого к-ва мелких файлов, большых файлов, файлов с разных дисков: т.е. дает возможность переключать контекст «бутылочного горлышка» между скорость сети/ производительность ЦП / производительность файловой подсистемы
Из неявных минусов:
1. Восстановление при полной потере директора/каталога. Из єтого следует:
а. Всегда иметь бекап БД (каталога), мы используем Master-Slave. Плюс дампы БД и хранение отдельно.
б. Всегда отдельно хранить bootstrap-ы
в. Использовать multi-direct/multi-storage схему
Используем Gitlab + gitlab-ci (runner). Удобно. Runner проганяет тесты, делает билд, и если все ок — деплой. Срабатывает по тригеру пуша в мастер ветку GIT
Еще раз повторюсь — главное понимать, важная информация передается, или так: просто поболтать.
По своей специфике работы, директор — второй или третий человек по к-во разговоров за неделю, но он очень близок к ИТ.
Если взять сферического директора да поместить его, если директор говорит что ему нужно, то он должен знать риски на которые он идет, в т.ч. финансовые — то о чем вы писали выше.
Кто будет платить за любое решение? — тот кому оно нужно. Не нужно обезопасить себя — не нужно и платить. Вы полностью открытая контора — еще меньше проблем.
С другой стороны, если вы построили супер-мега надежный и безопасный канал связи, а директор говорит по нем исключительно в публичных местах — то это тоже не панацея.
Так что всё зависит от конкретной политики фирмы в отношении безопасности, и есть ли такая политика и комплекс мер по ее поддержания.
А оно того стоит, что б не использовать шифрование в корпоративном сегменте?
А информация, которую директор принимает через не зашифрованные соединения важная или нет? Есть ли там ком. тайна, или другая информация, потенциально опасная для бизнеса?
Тут самое главное понимать, важная информация передается, или так: просто поболтать.
Для второго варианта существует схема с «несекьюрным» вторым сервером почты или телефонии, который видит только «публичные» письма, или письма помеченые как «открытые».
iptables-persistent — обвязка над командами iptables-save > /etc/iptables/rulesXXX, iptables-restore, iptables flush. Т.е сохраняет текущие правила в файлик, потом считывает. Отдельно можно конфигурировать для IPv4/IPv6.
Вот есть проект для терминал сервера с загрузкой посети (тонкий и толстый клиенты) ltsp.org/. Возможно будет немного меньше велосипедов. Но есть ограничение по дистрибутивам.
«Не удивительно, что вы все вымерли…» (Парк Юрского периода)". Возможности IP телефонии намного шире и более гибкие нежели обычных мини-АТС. И информации в понятном виде намного больше. А требования «бизнеса» об интеграции с CRM? Возможность CallBack? Запустить какой нить скрипт по DTMF? Динамическая IVR? Подключения служб VoIP? А вопрос по поводу «Что делать если сгорело», что нужно для восстановления мини-АТС и комп. АТС?
Есть и минусы: масштабируемость на базе Asterisk. Но есть решения. Второй — безопасность (звонки на кубу). Так что везде есть свои нюансы.
Подскажите, пожалуйста, просто ли добавить в дайлплан на вебморде вызов FastAGI скрипта так как сам работаю с голым (консольным) Астериском. И есть ли вызов внешней команды для конвертации записаного разговора (для того что бы сохранить запись в формате OGG- через sox конвертор, например). Долго «редактировал», получился второй коммент.
По поводу «Dynamic members». Вашу логику более удачно было бы реализовать через пенальти. Тогда через правила очереди можно менять пенальти для агентов. В итоге никому никуда «скакать» не нужно.
Мне по долгу службы приходится собеседовать кандидатов на должность операторов тех. поддержки одного регионального провайдера. Что нужно от кандидата? — нормальная речь, соображалка, стремления учиться и быстро усваивать материал. Всё. Что я делаю? Я ограждаю круг вопросов поверхностно(мораль, етика, интернет технологии, хоби, и все что взбредет в голову), потом по нужным мне темам (интернет технологии, «что бы вы сделали в такой ситуации?» ) копаю в глубину до нужного мне уровня. Бывает кандидат вообще ничего о «ping/nslookup» не знает, бывает говорим про VLAN (уровень езернет фрейма). Всякие бывают. Очень мало людей знают все что мне нужно, а те кто все знают — я их спрашиваю «Что вы хотите от роботы с такими знаниями? оО». После этого я даю кандидату (если он подходит по критерию «не растерялся, нормально ведете в стрессовой ситуации») 7-12 дней на «изучение пробелов» в его ответах и карт-бланш на доступ в отдел тех поддержки с приставаниями по вопросах «как все работает? а что это за кнопочка и зачем она нужна? и т.п.» к нашим специалистам. После я проверяю что человек выучил, в чем разобрался, спрашиваю «Нравится ли тебе такая работа». Если все ок — принимаю, иначе — если интересно, подучите и через пару месяцев подайте резюме на вакансию еще раз, если будут места — посмотрим. Идеально когда на должность 2-5 человек. Тогда открыто говоришь им молв конкурс, вот реальные люди, вот реальные темы. Вперед.
не знаю на сколько такое собеседование по «фен шую», но пока «мне везет» на хорошие кадры.
Хочу одежду с какой то наклейкой (как сигналка в супермаркетах на товарах, что б не воровали), и стиралку которая это умеет распознавать. В наклейку вводить код продукта. А к коду продукта привязывать возможные програмы для стирки. Закинул в машинку, выбрал сушку/стирку бытрую/полную и нажал кнопку старт. Еще с каким то уведомлением на комп(ех… что б так пельмени варить), что молв достиралось.
1. Резервное копирование на удаленный хост:
— Копирование идет на StorageDaemon, который может быть на любом компютере. Причем для разных типов бекапа можно использовать разные файлохранилища: для полных бекапов — один, для диф — другой, для 2х-недельныз — третий.
2. Шифрование
— Бакула умеет шифровать как хранимую информацию, хотя можно ее хранить и в том же трукрипте, так и передаваемую информацию. Но есть пара ньюансов. Первый — метаданые не шифруются (название файлов, пути, владелец… ), второе — восстановить при полной потере директора — use the force, Luke.
3. На одному клиенту может быть несколько одновременных задач которые будут писать на разные файлохранилища используя/неиспользуя сжатие и шифрование. Такое дает определенную гибкость и повышение производительности при копирование большого к-ва мелких файлов, большых файлов, файлов с разных дисков: т.е. дает возможность переключать контекст «бутылочного горлышка» между скорость сети/ производительность ЦП / производительность файловой подсистемы
Из неявных минусов:
1. Восстановление при полной потере директора/каталога. Из єтого следует:
а. Всегда иметь бекап БД (каталога), мы используем Master-Slave. Плюс дампы БД и хранение отдельно.
б. Всегда отдельно хранить bootstrap-ы
в. Использовать multi-direct/multi-storage схему
По своей специфике работы, директор — второй или третий человек по к-во разговоров за неделю, но он очень близок к ИТ.
Если взять сферического директора да поместить его, если директор говорит что ему нужно, то он должен знать риски на которые он идет, в т.ч. финансовые — то о чем вы писали выше.
Кто будет платить за любое решение? — тот кому оно нужно. Не нужно обезопасить себя — не нужно и платить. Вы полностью открытая контора — еще меньше проблем.
С другой стороны, если вы построили супер-мега надежный и безопасный канал связи, а директор говорит по нем исключительно в публичных местах — то это тоже не панацея.
Так что всё зависит от конкретной политики фирмы в отношении безопасности, и есть ли такая политика и комплекс мер по ее поддержания.
А информация, которую директор принимает через не зашифрованные соединения важная или нет? Есть ли там ком. тайна, или другая информация, потенциально опасная для бизнеса?
Тут самое главное понимать, важная информация передается, или так: просто поболтать.
Для второго варианта существует схема с «несекьюрным» вторым сервером почты или телефонии, который видит только «публичные» письма, или письма помеченые как «открытые».
Довольно удобный скриптик.
Есть и минусы: масштабируемость на базе Asterisk. Но есть решения. Второй — безопасность (звонки на кубу). Так что везде есть свои нюансы.
не знаю на сколько такое собеседование по «фен шую», но пока «мне везет» на хорошие кадры.
Очень помогает блеклист/форваринг входящих звонков с города на джсм-шлюз.
Не забываем, что 2 астреиска можна соеденить иаксом (:
Разве я хоть где то упомянул страну, или вы смотрели мой профиль?.. Зачем же такое писать, не уточнивши что и как?