shurshur, арч стабилен! Не знаю, что у Вас разваливается. Спектр ПО на моих арч-инстансах разноообразен по самые гланды. Говорю же, 5 лет на десктопе и на серверах. Десктопное, включая вэйланд и софта для него, swaywm, openoffice, qcad, с двумя мониторами с разным PPI, и одинаковым размером, без блюров, размытия шрифта. То есть, даже это десктопное не ломалось 5 лет. Серверное - 3 года lxc, lvm, qemu/kvm, nginx, postgres, docker и еще вагон. Проблем, связанных с обновлением не было совсем, особенно если читать. Единственное, что было - это переименование сетевого интерфейса или его алиаса как-то сделали, systemd не подхватил новое. А под десктоп сломался звук когда репа перешла с pipewire на wireplumber. Для меня на чаше весов это намного менее трудоёмко, чем искать проблемы при апгрейде с дебиан11 на дебиан12, условно. Про переустановку с нуля я и не говорю. При этом фиксы выходят тут же, или "воркэраунд" есть на офсайте. Арч, на котором гипервизоры, то один раз установив его и настроив, вы больше к установке ОС на хост не возвращаетесь. Ядро опять же свежее с новыми плюшками. Если же у вас в качестве гипервизора дебиан, вам рано или поздно придётся потратить время на апгрейд до свежей версии и всё, что с этим связано. С арчем вы это плавно обходите. Если приведете пример из своего опыта, что в арче у Вас регулярно ломалось за последние 5 лет, будет интересно. Если же вы не работаете на арче, а лишь когда-то сложился такой стереотип, то ваши утверждения, к сожалению не релевантны.
Drno в мире линукс нет понятия "де факто".
Телодвижений для дома он тоже требует минимальных. Но с другой стороны, я же сразу и сказал, что лучше если первым дистром будет не арч, хотя это тоже зависит лишь от стремлений, так как арч-вики со статьей по инсталляции сходу знакомит пользователя с базовыми вещами на практике.
Drno, за всех говорить - глупо.
Кастательно ломучести арча - это сказки из нулевых: 5 лет арч на десктопе. Года три на 9 серверах, в том числе и под гипервизор. Полёт ахерительный.
Я бы поправил: "Сейчас" арч не нужен. Чтобы понять прелесть арча, надо сначала посидеть на других дистрах.
Не иметь такой сущности как "мы выпустили новый релиз дебиан/убунту" - это многого стоит. Безусловно, есть у арча и минусы, но совокупность стабильности, свежести пакетной базы и философия роллинг-релиз покрывают их с лихвой.
KarlJohnson, Восток - дело тонкое. Там к провайдеру надо так "ээ, худжаин, илтимос, ёрдам берийла. Ош пош, любой нарса. Интырнет ишламаяпти". ))
Если без шуток, то наверное, два варианта:
-посетить офис, со скриншотами, где идёт флуд на Ваш порт. В ходе личного общения люди обычно выслушивают. Главное - не грубить, при всей трешовой ситуации.
-или можно жалобу накатать в ваш аналог "потребнадзора". Обычно их побаиваются.
яндекс диск, облако мэйл, гугл диск, mega nz? В зависимости от объемов, выбираете тарифы.
Клиентская программа на сервер. Расшаривание каталога (папки) с этого акка для определенных акков этих облаков. Клиентские программы на компы команде. Не вариант?
Руслан Малиновский, поговорил тут с пацанами по вашей теме. В общем, мои вышеизложенные предложения в любом случае рискованные. Если со стороны проверяющих будет спец по телефонии, то шансы, что вас нахлабучат практически 100%. Лицензия нужна!
Тут таким образом чистых вариантов два: первый - это получение лицензии, второй - пилить модуль для астерисков, который будет взимодействовать с вашим основным сервисом и предлагать этот модуль установить на атс заказчика. Что-то типа itgrix (интеграция астериск для битрикс24).
Прошу прощения, что ввел в заблуждение.
Руслан Малиновский, мммм.... тут я всё - сдулся. ) Не подскажу.
Технически можно направлять запись звонка на железо заказчика (заказчик на своем железе может делать все что угодно с контентом звонков, главное дать в линию инфу, что разговор записывается). А ваш сервис по API подтягивает эти записи с сервера заказчика себе в бэкенд и отображает во фронте личного кабинета заказчика. Плюс всякие заялаления о неразглашении и конфиденциальности между собой составите.
Я мало представляю, как эту схему можно размотать на нарушения. Но тут ложка дёгтя - согласится ли заказчик прописать такой пункт в договоре, и вообще насколько приемлемо поднимать перед ним такой вопрос.
Всё что знал по-фински, сказал (с). Чем смог, короче.
Руслан Малиновский, если я правильно понял этот коммент, то смотрите:
Я предложил не писать в договоре фразу "маршрутизация телефонных звонков" только для того, чтобы у потенциального проверяющего не сработал триггер "опа, звонки" и он не стал тратить своё и ваше время и нервы на погружение в детали. Исход будет зависеть от морально-волевых качеств проверяющего и компетентности юриста,
Если же напишете "обслуживание сценариев работы транка, который предоставляет заказчик", то тут все прозрачно и действительно отражает суть того, что вы делаете.
Мало того, технически можно настроить сервер телефонии так, что через него не будет идти медиа-трафик (rtp. голосовая связь). Сервер будет просто соединять двух абонентов напрямую, а через себя пропускать только служебные пакеты управления этим соединением.
Но не это главное. Главное то, что вы - не оператор связи, который предоставляет выход в сети общего пользования.
Транк вам дает заказчик и говорит настройте логику работы мне, плиз. Не вы заказчику свой транк даёте и берете за это деньги, а он - вам.
Руслан Малиновский, Да. И думаю в договоре лучше не писать "маршрутизация звонков", а написать "обслуживание и настройка сценариев транка, который обязуется предоставить заказчик". Что-то типа этого.
Но опять же, уточню, я - технарь. не - юрист (лишь, лет 20 назад был связан с контролирующими органами в сфере связи и информатизации). И как технарь, исходя из ваших комментариев к вопросу, я лично не вижу в вашей схеме факта оказания услуг связи. Но так или иначе мой коммент нельзя рассматривать, как достоверный. Просто попробуйте подойти к формулировке с этой точки зрения.
Руслан Малиновский, Я не юрист. Но чисто логически можно посмотреть так: Вы управляете сценариями работы транка заказчика. Заказчик просто даёт вам полномочия настраивать условия эксплуатации транка. Вы не оператор, вы не выделяете номера PSTN, вы просто интегрируете (по просьбе заказчика, на возмездной основе) транки заказчиков в свой сервис, по предоставленным заказчиком sip (whatever)-кредам.
Заказчик уже и так платит оператору сети общего пользования согласно его тарифам, грубо говоря поминутно. Вы не - автобусный парк, вы - лишь проверяете проездные билеты в одном из автобусов, который арендует у автопарка ваш заказачик, и по просьбе этого заказчика.
Вы настраиваете "логику" обработки вызовов, вы не арендуете пул номеров с целью перепродажи.
Еще база, грубо обобщенная, для понимания такая - лицензируются те услуги связи, качество которых выражается в цифровых значениях и прописано в нормативах. Например, количество неудачных вызовов из выполненных 10. И так как, вы не можете на это никак повлиять, потому что не владеете/не_арендуете программно-аппаратный комплекс или транспортные сети, вы не берете поминутную плату за совершенный вызов и прошедший через сервер на котором у вас приземлён транк (или взаимодействует, как пир, с сервером телефонии заказчика), вы не оказываете услуги связи.
Как обычно, огромное спасибо! GRE работает на все деньги!!!
А ведь изначально выбрал ip-ip, предполагая, что это самый простой туннель и с минимумом оверхэда в ip-пакете.
Это логично, бесспорно. Но мне для начала в режиме онлайн хотелось бы увидеть, кто именно вызывает нагрузку. Урезать можно, но это как гадание на кофейной гуще. Ибо сервисы не стендэлоун каждый, а связка.
Посмотрел описание. Там оверхед для меня. :) И насколько понял видео не пишет, только скриншоты.
Но спасибо в любом случае. Добавил в закладки, на будущее.
Я бы для начала изучил какую ответственность Вы, как настройщик, несёте за то, что "сливаете" данные одного из сегментов "Безопасного города" в облако (читать третьим лицам). Да и потом как бы не пришлось доказывать следователю, что вы действовали не по злому умыслу и, что организованный Вами "стык" не несёт в себе уязвимостей для атаки на всю сеть.
Когда опубликовал вопрос, потом понял, что предложат зашифровать весь хоум и, что я был не совсем корректен в описании своих "хотелок". Предполагаем, что пришли с аудитом. Нужно показать рабочую систему, но без раскрытия данных в этих двух файлах. Лайтовая версия трукриптовского скрытого раздела, когда вводя тот или иной пароль, система загружается либо в decoy, либо в hidden. Поэтому, да, был не прав спрашивая про ввод пароля на этапе входа в систему - тут именно спрятянный в дебрях скрипт вызывать уже после входа. Но вот чем?
p.s. Арчлинукс при установке ни о чём не спрашивает. :)
Drno в мире линукс нет понятия "де факто".
Телодвижений для дома он тоже требует минимальных. Но с другой стороны, я же сразу и сказал, что лучше если первым дистром будет не арч, хотя это тоже зависит лишь от стремлений, так как арч-вики со статьей по инсталляции сходу знакомит пользователя с базовыми вещами на практике.