Tech, добавлю, что для исключения раскрытия данных при наличии физического доступа надо все ключи закрывать пассфразами и использовать агенты (ssh-agent, gpg-agent). Если всё правильно сделать, ключи будут использоваться только на той машине, с которой залогинен, а дальше прокидываться по ssh. И секретный ключ можно держать на железном носителе типа yubikey (самый известный, есть и другие варианты). Да, это придётся поразбираться и повозиться. Да, yubikey стоит некоторых денег и его может быть сложнее купить в условиях санкций.
Лучше вынести секреты в отдельный файл, а его шифровать или gnupg, или ansible-vault. Приватный ключ для gnupg в любом случае не надо класть в git, а доставлять отдельным механизмом.
Для управления шифрованными файлами в целом можно использовать pass https://wiki.archlinux.org/title/Pass, который комбинирует gnupg и git для хранения шифрованных файлов с неплохим cli-интерфейсом.
Ну а вообще я бы посмотрел на готовые dotfiles-менеджеры типа yadm.
Из самого простого что-нибудь типа https://osmo.mobi
Даже в бесплатном варианте можно мониторить некоторое количество объектов, клиент osmodroid для смартфонов или iosmo для огрызков.
Также есть в разном другом софте возможность настроить и дёрнуть координаты по URL, например, в osmand.
В UNIX тоже обычно расшаривают через samba, так как nfs немного для другого предназначен, работает поверх rpcbind в локальной сети безо всякой авторизации (ну, kerberos можно навертеть, но это задача с десятком звёздочек) и работать будет только на UNIX-системах. На телефонах, например не годится.
Я у себя шарю через самбу и одновременно через nextcloud (как external storage: local). В итоге можно или через тот же vlc на телефонах смотреть/слушать видео/аудио, или прям в мобильном клиенте nextcloud даже не только в локалке, но с авторизацией.
system_sudo, подход django состоит в том, что только в отладочном режиме django обслуживает файлы (это накладно и блокирует django при запуске в runserver, который по определению однопоточный). Статику полагается перекладывать в отдельнй каталог из всех django-приложений (коих может быть много в большом проекте) с помощью manage.py collectstatic, а этот каталог нужно явно раздавать через веб-сервер мимо django. Для медиафайлов всё почти так же, только медиафайлы сразу же кладутся туда, где их будет забирать веб-сервер всё так же мимо django.
Код python без отступов - не код. В нём вообще ничё понять нельзя. Для оформления кода на панели есть предпоследняя кнопка, используй её, иначе никто даже вникать в вопрос не будет.
nedland, эта ссылка скорее всего на m3u-лист, и его не так надо качать, а достав из него список ссылок и склеив эти файлы в mpeg-ts, который потом лучше правильно обработать. И то, m3u поддерживает криптографию, при которой видеофайлы шифруются и всё это становится не так просто.
Всё это умеет youtube-dl, но его надо правильно готовить. Придётся сидеть и вникать. Я в своё время ломал anidub и некоторые другие сайты и таки справился.
1. Индекс, в котором хранится offset начала каждого диапазона записей для префикса ключа (диапазона ключей).
2. Индекс можно сделать в виде дерева, где иерархически ключ разделен на части. Например, ключ длины 4, 8, 12 адресует смещение и длину блока с записями с префиксом ключа такой длины.
3. Можно использовать хеширование ключа, но скорее всего не получится быстрее для отсортированных данных, ведь индексироваться будет каждая запись отдельно.
А дальше научиться как базы выбирать, когда эффективнее full scan файла, а когда - хождение по ключу.
Пример (на базах данных, для понимания):
Пусть у нас есть таблица с записями о платёжных операциях, в котором есть поле bank (текст, bank_id - неважно, просто есть). Тогда если выбирать из таблицы маленький банк (какой-нить Мухосранский Народный Банк), то поиск по индексу эффективнее: мы сходим в индекс (который меньше самой таблицы), получим немного смещений в основной таблице и вычитаем немного блоков с диска с данными. Если же выбрать Сбербанк, который упоминается в более чем 80% записей, то хождение по индексу будет означать, что мы всё равно вычитаем всю или почти всю таблицу, и обращения к индексу увеличат наши расходы больше, чем мы сэкономим. Поэтому у зрелых баз данных есть разные сложные оценки запросов, включая всяческую эвристику и накопленную по предыдущим запросам статистику.
Ну так вот, плясать с файлом в 10 Гб надо от того, какие именно действия с ним производятся. Если, например, нужно всё равно перебирать все записи - то всё равно придётся перебирать все, и ничего мудрить тут вообще не надо. Дисковый кэш в ОС всё сделает за нас, если читать мы будем последовательно хоть по байту, хоть по мегабайту.
Если же профиль конкретный действий сильно разный (иногда читаем всё, иногда одну запись), то может оказаться эффективным реализовать два разных алгоритма, один из которых будет использовать индексирование, а другой нет.
В целом записи по 20 байт слишком маленькие, чтобы индексировать каждую запись. Но так как данные отсортированы, то индексировать диапазон может быть приемлемо - особенно если грамотно выбрать длину диапазона.
Наконец, я бы попробовал рассмотреть вариант просто загрузить этот файл в полноценную базу данных и отдал бы всю мороку по оптимизации доступа ей. Возможно, это будет быстрее наколеночных решений.
Нужно понимать, что любые такие способы это больше полумеры. Надёжный только один: не принимать платежи извне РФ, находясь в РФ, и даже с Казахстаном есть риски. Например, открыть юрлицо или ИП в совсем другой стране. Но при таких малых оборотах это слишком накладно, так что придётся искать рискованные способы с высокими комиссиями.
Roman32V, во многих CRM и не только CRM есть готовые интеграции или отдельно доставляемые модули с разными поставщиками. У кого-то REST, у кого-то SOAP, у кого-то SMPP, и суть каждого модуля в том, что его включаешь, забиваешь полученные у поставщика реквизиты и вот тебе готова интеграция.
То же самое с интеграциями с менеджерами, в том числе через коммерческих провайдеров (Viber, WhatsApp), тот же живосайт или битрикс24 поддерживают разных.
pfg21, тоже вариант. Просто это работает, когда точно знаешь занятые IP и лучше с мак-адресом сразу. А когда хочется забронировать "вот эти не брать", то лучше как раз указать какие брать можно.
MeredithMcGlynn, у меня был случай, сеть условно 192.168.0.0/24, шлюз .1 на оборудовании провайдера, DHCP-сервер 192.168.0.2 на собственном оборудовании организации. Мигнуло питание, оборудование провайдера ожило позже собственного, и IP .1 был DHCP-сервером выдан какому-то из компов. Причём интернет даже слега работал для тех устройств, которые получали правильный ARP шлюза :) Я тогда разбирался как в том устройстве ограничить диапазон выдаваемых IP, чтобы такое не повторилось.
Так что сценарий выдачи уже занятых IP вполне возможен. Например, если на момент выдачи с точки зрения DHCP-сервера занятый IP не был виден. Или если DHCP-сервер криво написан и не проверяет это нормально...
Смотря почему именно не включается. Вытаскивал файлы с Samsung с умершим экраном, загрузил, подключил, вслепую подтвердил подключение по USB к файлам (примерно представляя, где соответствующая кнопка должна быть, затем вытащил.
Вообще, можно начать с попытки попасть в recovery mode. Особенно если прошит кастомный с нормальными расширенными функциями. Если даже в recovery нельзя попасть, то скорее всего без прямого подключения к к SD-карточке на плате ничего не получится.
