Всем привет. В своей предыдущей статье я описал общую идею создания площадки, где люди смогут объединяться в одну общую железячную сеть и использовать мощности друг друга. В основе этой идеи лежит идея создания распределенного кластера Kubernetes, к разворачиванию которого я планирую в скором времени приступить.
Но на начальном этапе важно подготовить сеть из однородных линукс машин, на которых стоит абсолютно одинаковый линукс, чтобы не пришлось решать одни и те же проблемы по несколько раз. А это может быть, т.к. все дистрибутивы линуксов имеют свои особенности, например, в плане того, какие модули ядра стоят как модули, а какие вкомпилены в ядро.
Поскольку ожидается, что изъявить желание подключиться к этой сети может любой пользователь с любыми железом и операционной системой (например, не только линукс, но и bsd системы и андроид, который является сильно урезанными линуксом), то хотелось бы иметь скрипт / программу / проект, который сможет сравнять все системы до одинаковых однородных линуксов по причинам, описанным выше. При этом в качестве реального железа может выступать и виртуальное, когда человек на своем оборудовании отрезает под виртуальные нужды часть своих мощностей и отдает их в сеть hardware банкинга.
Сборка своего "хакерского чемоданчика", или как я портировал ПО от Pineapple Nano в доработанный роутер MR3020, все подробности в статье. Вперед!
Здравствуй дорогой читатель данного руководства. Меня зовут Андрей, и нет, я не алкоголик, а разработчик встраиваемых систем на базе Linux.
Данная статья является кратким руководством по созданию образа диска с несколькими разделами, куда можно было бы записать всякую всячину для передачи заказчику, а в дальнейшем и на производство.
Для чего это нужно? Все процессорные платы, разрабатываемые нашим предприятием, обладают слотом для sdcard и установленной на плате mmc. Загрузка системы производится либо с sd, либо c mmc. sd-карта является, как правило, временным решением, подкупает простотой установки. А mmc является постоянным решением, куда устанавливается уже финальное программное обеспечение. Переключение между способами загрузки осуществляется перемычками (джамперами на плате).
Я занимаюсь разработкой АТС с открытым исходным кодом MikoPBX.
Недавно познакомился с проектом tg2sip. Шлюз позволяет подключить Telegram аккаунт к офисной АТС, принимать и совершать звонки.
После настройки шлюза, решили, что было бы неплохо после завершения телефонного разговора отправить клиенту клавиатуру для оценки качества обслуживания.
При попытке реализовать функцию столкнулись со сложностями:
- Пользователь не может отправлять / пересылать клавиатуру другому пользователю
- Бот не может писать пользователю, если тот на него не подписан
Как же быть? Решение опишу под катом
Туториал по основам докера в котором простыми словами объясняется, как собирать образы и разворачивать контейнеры. Тут же можно узнать, чем контейнер отличается от виртуалки, что такое образ и увидеть простой кейс.
Ещё со студенческой скамьи у меня остался ноутбук Fujitsu, который тогда верой и правдой мне служил для постижения азов Паскаля и Си, а также для серфинга интернетов и героев 3.
Конечно же, более-менее современные ОС не рассчитаны на машину с одноядерным процессором Celeron и 1Gb оперативной памяти, поэтому я обратился к легким
дистрибутивам линукса.
Целью было поупражняться с линуксом, получить работающую консольку для каких-то повседневных задач, вроде запуска какого-нибудь простейшего бота, установки напоминалок крона или хостинга статического сайта.
NGINX — это HTTP-сервер и обратный прокси-сервер, почтовый прокси-сервер, а также TCP/UDP прокси-сервер общего назначения, изначально написанный Игорем Сысоевым. Уже длительное время он обслуживает серверы многих высоконагруженных сайтов.
Однако кросс-компиляция NGINX практически невозможна, поскольку разработанные Игорем Сысоевым скрипты конфигурирования исходного кода в большинстве случаев используют так называемую процедуру «Try Run».
Те кто знаком с утилитами Autoconf, Automake знают, что проверки необходимых параметров системы и кросс-компилятора осуществляются различными процедурами, которые, в свою очередь, могут применять попытки сборки исходного кода (Try compile), линковки объектных файлов (Try link) и, наконец, попытки запуска тестовых программ (Try Run).
Естественно, если речь идет о кросс-сборке, операции «Try Run» недопустимы, ведь мы не можем запустить программу, собранную под целевую архитектуру отличающуюся от архитектуры машины сборки на самой машине сборки.
В Autotools проблемы, связанные с невозможностью запуска целевых программ на сборочной машине в некоторых случаях решаютcя кешированием переменных, которые могу быть переопределены пользователем в файле --cache-file или заданы в командной строке вызова скрипта ./configure.
Скрипты Игоря Сысоева не предусматривают такого переопределения машинно-зависимых величин. Однако величин, которые необходимо задать во время конфигурирования исходных кодов NGINX достаточно много. К ним, в первую очередь, относятся размеры типов данных. Именно с них мы и начнем.
Начиная с Kubernetes 1.6, RBAC политики включены по умолчанию. К тому же использование этих политик помогает безопасно управлять вашим кластером. Раньше нам приходилось вручную создавать подобные политики, сервисные аккаунты и пользователей. Для каждого нового проекта мы проделывали ручные операции, которые отнимали много времени. Особенно создание пользователей, так как требует множества мелких манипуляций. Готового решения, удовлетворяющего нашим требованиям, нам найти не удалось, поэтому мы написали terraform модуль, который упрощает этот процесс. Данный модуль позволяет создавать сервисные аккаунты и пользователей, а затем генерировать готовые конфигурационные файлы (kubeconfig) для них. Также при помощи данного модуля можно создавать роли, кластерные роли и привязывать их к определенным сервисным аккаунтам, пользователям или группам. Модуль можно найти в нашем GitHub репозитории. Для использования модуля потребуется terraform >= 1.0.0 и kubeconfig, с административными правами.
На моей домашней машине вот уже 7 лет работает пара дисков, объединенная в soft raid1. И вот на днях один диск в зеркале наконец начал сыпаться. Появился повод переустановить систему с нуля и начать использовать шифрование, которое 7 лет назад не было задействовано. В процессе гугления о состоянии дел в конфигурации LUKS поверх mdadm я вышел на статью сравнивающей производительность zfs vs mdadm/ext4. А потом нашел другую статью с тестированием производительности зашифрованных дисков использующих LUKS и zfs. Согласно обеим статьям zfs демонстрирует весьма неплохую производительность и я решил попробовать ее в деле.
Две разные системы (win + linux) на одной аппаратной базе - реальность. В этом нет ничего нового или инновационного (на данный момент времени), но если требуется максимальная производительность гостевой системы, то не обойтись без проброса реальных устройств в виртуальную машину. Проброс сетевых карт, usb-контроллеров (etc) экстраординарных особенностей не несёт, а вот попытка "шаринга" ресурсов видеокарты и процессора вполне может принести некоторое количество проблем.
Итак, а для чего, собственного говоря, городить системы с полнофункциональным использованием ресурсов GPU и CPU? Самый простой и очевидный ответ - игры (широко известный факт - если не большинство, то очень многие, написаны под ОС Windows). Другой вариант - полноценное рабочее место с возможностью запуска требовательных приложений (например, CAD-софта), быстрым бэкапом (скопировать файл ВМ куда проще, чем создавать полную копию HDD/SSD) и опцией полного контроля сетевого трафика гостевой системы.
Оригинал: https://klarasystems.com/articles/exploring-swap-on-freebsd/
Свободная память = память, потраченная впустую? Как использовать swap наилучшим образом.
Для современных Unix-систем, таких как FreeBSD, термин “swapping” (подкачка памяти) означает операции по выгрузке данных из памяти на диск (устройство подкачки) и обратно, осуществляемые по требованию.
Процесс вывода происходит в ответ на отсутствие свободной памяти в системе: ядро пытается вычислить страницы памяти, к которым возможно не будет производиться доступ в ближайшем будущем, и копирует их данные на диск, чтобы сохранить до востребования.
Процесс выгрузки данных запускается при нехватке свободной памяти в системе: ядро системы вычисляет страницы памяти, которые скорее всего не будут нужны в ближайшем будущем, и копирует их содержимое на диск, на котором данные хранятся до востребования.
Если приложение пытается получить доступ к данным, выгруженным на устройство подкачки, этот процесс блокируется до тех пор, пока ядро системы не извлечет необходимые данные с диска. После этого, работа приложения возобновляется в обычном режиме.
Описанная технология выглядит весьма рациональной. Объем памяти дисков обычно больше объема RAM, так почему бы не использовать их для кэширования редко используемых страниц памяти? Однако, для многих опытных администраторов процесс подкачки памяти до сих пор воспринимается как некорректное поведение системы. И этому есть объяснение: до недавнего времени диски, используемые для подкачки памяти, имели задержки доступа в миллионы раз выше, чем у RAM.
Здесь лежит окончание "расследования" Новогодний детектив: странный хайзенбаг в «питоньих» часах.
Изначально хотел просто обновить статью и написать соответствующий комментарий, но понял что апдейт выходит чуть не длиннее самой статьи.
Напомню краткое содержание предыдущей части: python, как впрочем и всё на нем написанное, временами прыгает в будущее, а конкретно в 2023-й год в локальной временной зоне, и по некоторым данным в 2024-й в UTC/GMT (но это не точно) и побыв там некоторое время возвращается обратно в настоящее.
Во время прыжка оно ведет себя довольно стабильно (т.е. считает нано-, микро- и миллисекунды, а то и секунды, как будто время идет как ни в чём не бывало) в 2023-м т.е. локально, при том что в результате повторных прыжков время вновь продолжается как будто по возвращению оно (время) течет в какой-то параллельной вселенной. Однако странное его "отражение" в UTC/GMT, ну то что как будто бы в 2024-м, выглядит менее стабильно, ибо для него наблюдается странные дрейфы дополнительно к смещению прыжка.
Хотя куда уж страннее.
makeheaders нет нужды делать больших изменений в исходном коде, но, если есть такая необходимость, кое-что в нём можно и изменить.
Я считаю , что это очень полезный инструмент , он позволяет следить за состоянием ваших пайплайнов, job-ов и мониторить переменные окружения, можно отслеживать статусы, продолжительность, и на самом деле там есть очень много интересных настроек
Всем привет!
Продолжаем дайджесты новостей и других материалов о свободном и открытом ПО и немного о железе. Всё самое главное про пингвинов и не только, в России и мире.
Главные темы нового выпуска:
И многое другое…
В составлении дайджеста мне помогали qark, invasy и 6 пользователей через нашего Telegram бота [→], приглашаем вас тоже помочь нам через этого бота.
Ещё — мы не только составляем FOSS-дайджесты, но и автоматизируем процесс, все 3 проекта автоматизации тоже являются FOSS, их можно посмотреть на GitHub [→].
Привет, Хабр!
Надеюсь, ты уже слегка отошёл от новогодних праздников и возвращаешься в привычную колею. Лично я эти длинные выходные терпеть ненавижу и, посмотрев, по традиции, режиссёрские версии "Хоббита" с "Властелином Колец" дня за 3-4, начинаю от скуки лезть на стену и остервенело искать, чем бы себя занять. Не стал исключением и прошедший год - в этот раз сердце успокоилось с помощью авантюры с участием бриджей Тора, ораклового облака и вполне реальной возможности заполучить ценный лут.