Что мешает сделать копию docker-compose.yml и отредактировать в нём что угодно? А затем поднять с ним сервис (-f имя_файла.yml). Оригинальный файл не пострадает.
Нужна не выжимка, нужно отличать красные строчки от чёрных. С учётом того, как "офисные пакеты" умеют гадить в форматирование, это может оказаться даже сложнее, чем кажется. Я не уверен даже, что ChatGPT поймёт вопрос правильно - не то что сделает пригодный результат.
Мода на нейросети по любому самому плёвому вопросу - это ужасно.
Иван Гришов, если так важно числовые ключи в конец, то можно им добавить текстовый префикс, чтобы они не считались числами... Ну или поместить их в отдельное дочернее поле:
47911, нет, дело в местном провайдере или каких-то магистральных по дороге (скорее всего, тоже местных национальных). В LE проблем нет, если специально не накорячиться в настройках (а я слабо верю, что это сделано в продаваемых в ОАЭ iPhone), то всё будет работать повсеместно.
historydev, полезно даже не бэкапить виртуалки, а практиковать автоматизацию их разворачивания. Например, писать плейбуки для ansible, с помощью которых свежеустановленная система получает нужный софт с нужными базовыми настройками (nginx/php/docker/юзеры/права/настройки/итд/итп). Сайты, которые в сырцах (например, на php или python) разворачивать из git, но параметры конфигурации (например, реквизиты базы) не хранить в git. Обычная практика: в git лежит config_example.php с демонстрационным набором параметров, а для прода делают копию файла и меняют значения на реальные. Это рекомендация по личному развитию, если освоить подобный подход, то можно существенно улучшить поддержание текущих и поднятие новыхп роектов.
От паролей ssh лучше отказываться. Пароль должен или не использоваться совсем, или быть крайним вариантом на чёрный день и быть у каждого сервера разным автогенерированным и храниться где-нибудь там, где его легко не найдут!
Вместо пароля использовать ключи. Причём в хорошем варианте ключи хранятся только на локальной машине, а на удалённую (откуда практикуется ssh на какие-то ещё другие хосты) прокидываются через ssh-agent. Но для начала хотя бы просто начать использовать ключи. Можно вплоть до того, чтобы каждому серверу свой ключ, чтобы при утечке какого-то одного ключа не пострадало вообще всё.
historydev, если сохранять чистую систему - достаточно. Если начать копировать софт, скрипты и сайты из старой системы бездумно - можно вернуть обратно все дыры и уязвимости.
Я так понимаю в данном случае речь идёт о хосте для виртуалок? Тогда ставим всё заново, настраиваем гипервизор, если тянем из старой системы какие-то готовые скрипты - обязательно смотрим внутрь... Весь самосборный софт (если что-то ставилось из исходников) собираем заново, не копируем из иначального положения. И конечно же защищаемся от доступа на хост с этих виртуалок. Сами виртуалки (образы дисков), вероятно, можно сохранить, особенно те, которые не ломали. В теории, в них тоже могли записать вредонос прямо в структуры файловой системы, но это малореально, если вирус не писали какие-то суперспециалисты под узкоцелевое использование, ибо это очень сложно.
Be3up, в маркетплейсах продаются не только б/у и бракованные диски, но и чистый контрафакт. Особенно если покупать по цене в 2-3 раза ниже рыночных.
Вон, давеча на Али видел в продаже "оригинальные" диски брендов SAMSVNG и SVMSUNG, а также некие оригинальные WO Black (WO = Western Original). И формально не придерёшься: диски оригинальные, просто бренд... эээ... немного другой.
historydev, если у хакера был root, он мог заменить любую программу, библиотеку и даже ядро. Завтра в недрах какой-нибудь libpcre выполнится злоумышленный код и... и что? Так что доверять "чистоте" системы - огромный риск.
flexpc, прерывание 21h обрабатывается DOS (или виртуальной машиной DOS в Windows). Соответственно, совсем без операционной системы (ещё и не всё равно какой именно) это не будет работать.
Можно заменить на похожий вызов BIOS (забыл какое там прерывание было), тогда будет работать и без операционной системы на чистом железе, но внутри операционной системы уже не заработает (в виртуальной машине DOS будет работать благодаря намеренным усилиям "чтобы работало").
Можно вместо этого писать напрямую в видеопамять. Но тоже на чистом железе будет работать, а в операционной системе нет. И всё равно придётся учитывать видеорежим. Даже текстовый не всегда 80x25, а уж в любом графическом даже в пределах старого доброго 1024x768 вообще в видеопамяти цвета пикселей вместо символов, придётся иметь библиотку шрифтов и рендерить текст самостоятельно. А, конечно же, в protected mode процессора начнутся свои заморочки, причём там ещё имеется разница в работе памяти, если включить страницы.
О том, что такой код не будет запускаться на других архитектурах, я уже и не говорю.
Высокоуровневые языки скрывают все эти заморочки в стандартной библиотеке, причём BIOS или операционная система со своими прерываниями также могут рассматриваться как своего рода библиотека готовых функций.
Тут правильно говорят: в лучшем случае речь идёт о создании каких-то "макросов", которые позволят записывать те же низкоуровневые операции просто чуть другим словом. Глубокого удобства от этого не появится. Или всё же надо делать более высокоуровневый язык с библиотеками и стандартизированными интерфейсами.
Константин Фролов, не так просто подать напряжение, если надо его завести в micro USB порт и ничего особо нет... Но если ещё раз придётся такое ваять - я подумаю...
Pavlooo, ну дык где объявляеся переменная app? Вероятно, должно быть client? Ну и, конечно же, с пустым списком links ничего не произойдёт.
PS: Читаем правила сайта. Нельзя код картинками, надо текстом. И ещё надо удалить app_id/app_hash и не показывать публично. Их нельзя поменять, в отличие от токена бота!
Возможность включать VPN клиент для конкретных MAC-адресов
Это не так делается. Это надо этим мак-адресам выдавать заранее заданные IP или даже вывести их в отдельный vlan - и уже для них сделать policy routing. Это скорее всего уже или к микротикам, или к роутерам с нормальной поддержкой openwrt.
Константин Фролов, я знаю что длинный коаксиал нехорошо, но в данном случае вообще хрень вышла, я купил вариант с длинным USB и он от ноутбука ещё питался нормально, а от роутера модем ребутялся каждые несколько минут, видимо от нехватки питания. То что в итоге сделал - был единственный вариант, который я смог собрать из того, что тогда было в наличии у меня в деревне.
Операторам невыгодно, когда авторизуют "по звонкам", ведь невзятый звонок приносит доходу 0 рублей 0 копеек. Понятно, что они будут очень активно мешать подобным "сервисам".
Лучше не завязываться на такую авторизацию, а авторизовать через соцсети, Google Authenticator и другие средства, где головная боль по борьбе с клонами и авторегами будет чьей-то чужой, а не собственной.
Ну например запрос выполняется за 50 мс, тогда как ни крути, но в один поток больше 20 запросов не сделаешь.
Начинаем параллелить (тредами или asyncio), и тоже не можем бесконечно наращивать. Например, пусть, утрировано, эти 50 мс это чисто процессорный ресурс (на деле так не будет, это чисто иллюстрация), а у сервера 8 процессорных ядер. Тогда больше чем 160 запросов в секунду не выжать.
Собственно, если начать смотреть среднее время ответа, то можно даже примерно определить, в какой момент оно начинает расти, а общее число запросов за единицу времени расти перестаёт. Вот и нащупано узкое горлышко.
Ещё могут быть ограничения на число воркеров или длину очереди в web-сервере или в конечно приложении, размеры буферов итд итп. Варианты с ограничениями на конечного клиента тоже могут быть.
Короче, вполне может быть, что 30-40 - это вот реальный максимум.
