Русский
Русский
English
Авторизация
Ip-адрес
Восстановление пароля
Регистрация
Статистика
Реклама

Perl

Перевод Горячая четвёрка умирающих языков программирования

25.09.2020 16:06:58 | Автор: admin
Я занимался поиском лучших языков программирования 2020 года и наткнулся на страницы, на которых шла речь о языках, теряющих популярность. Я программист, и я понимаю, что любому программисту крайне важно знать о том, какие технологии являются актуальными, а какие нет.

Каждый программист это писатель.

Серкан Лейлек

Я, после того, как насмотрелся на отчёты о языках программирования, теряющих актуальность, выбрал 4 языка, которые, как я полагаю, уже не стоят того, чтобы их изучали. Я, ради подкрепления своих выводов, прибегну к некоторым показателям популярности языков. В частности, речь идёт об индексе PYPL (PopularitY of Programming Language Index, индекс популярности языков программирования), о данных Google Trends и о некоторых сведениях, которые можно найти на платформе YouTube.


Фрагмент рейтинга PYPL (источник)

Платформа YouTube использовалась мной в качестве источника данных о перспективности языков программирования через оценку популярности видеоуроков по соответствующим языкам.

Хочу отметить, что анализ рейтингов языков программирования способен оказать большую помощь тому, кто планирует построить карьеру в сфере информационных технологий. Дело в том, что эти рейтинги позволяют выбирать языки, которые стоит учить, а правильный выбор языка может оказать огромное влияние на профессиональный путь программиста.

Но хватит предисловий. Поговорим об умирающих языках программирования.

1. Perl


Интерес к языку программирования Perl стремительно падает. Хорошие показатели он демонстрировал в период с 2004 по 2009 годы, а после этого начался спад. Хотя этот язык пока и не мёртв, но он уже и не очень-то жив.

Информацию по нему не особенно активно ищут на YouTube и в Google. Например, есть видео по Perl, загруженное 4 года назад и набравшее всего 240 тысяч просмотров.


Видео по Perl

Кроме того, показатели языка идут вниз и в рейтинге PYPL.

Я решил сравнить Perl с каким-нибудь другим языком, с Python в данном случае, и обратился к Google Trends.


Сравнение Perl (красная линия) и Python (синяя линия), последние 12 месяцев

Как видно, красная линия, представляющая Perl, находится где-то на уровне нуля.

2. Haskell


Язык Haskell выглядит лучше, чем Perl. Он, к тому же, используется во многих крупных компаниях вроде Facebook и IBM. На YouTube есть видео по Haskell, загруженное 5 лет назад. Оно набрало 585 тысяч просмотров.


Видео по Haskell

Посмотрим теперь на показатели Google Trends, сравним Haskell и Python.


Сравнение Haskell (синяя линия) и Python (красная линия), последние 5 лет

Haskell, в сравнении с Python, выглядит более чем скромно. Синяя линия, представляющая Haskell, стелется по земле, а Python, представленный красной линией, показывает уверенный восходящий тренд.

3. Objective-C


Язык Objective-C, если ориентироваться на рейтинг PYPL, вырос в популярности на 0,2%. А что будет, если взглянуть на данные с YouTube?


Видео по Objective-C

Видео, загруженное 5 лет назад, набрало 250 тысяч просмотров.

Обратимся теперь к показателям Google Trends.


Сравнение Objective-C (синяя линия) и Python (красная линия), последние 5 лет

Конечно, многие всё ещё пользуются Objective-C. Но, хотя по этому языку есть вакансии, если вы строите планы на будущее и посматриваете на Objective-C, то вам стоит переключить внимание на Swift.

4. Visual Basic for Applications


Visual Basic for Applications, VBA, был у всех на слуху в 2004 году, а вот после 2009 интерес к нему начал падать. Я, например, изучал этот язык в школе.

Рейтинг PYPL указывает на то, что популярность VBA упала на 0,2%.

В моей ленте на YouTube видео по VBA мне видеть не доводилось. Возможно, это говорит о падении интереса к данному языку. Правда, когда я поискал подобные видео, мне попалось одно, загруженное 9 месяцев назад, набравшее 810 тысяч просмотров.


Видео по VBA

Если посмотреть на данные по VBA, которые имеются на Google Trends, то окажется, что интерес к VBA с 2004 года стабильно падает.


Сравнение VBA (красная линия) и Python (синяя линия), c 2004 года по настоящее время

В целом можно отметить, что VBA, несмотря на падение популярности, выглядит в сравнении с другими умирающими языками не так уж и плохо.

Python


Я занимаюсь серверной разработкой, используя Python. Я, кроме того, сделал несколько проектов, используя фреймворк Django. Что тут сказать мне нравится Python.

Это, если верить тому, что выдаёт Google, язык, который лучше других языков помогает в поиске работы в 2020 году.


Языки, знание которых помогает в поиске работы

Я, например, создал проект на Django. А именно, речь идёт о сайте с вопросами и ответами для разработчиков. Этот проект всё ещё в работе. Я расширяю его и занимаюсь его оптимизацией.

Python в рейтинге PYPL демонстрирует рост на 2,9%. Если поинтересоваться данными YouTube по просмотрам видео о Python, то окажется, что они, за короткие промежутки времени, набирают миллионы просмотров.


Видео по Python

Анализ исследования Stack Overflow


Выше я опирался на рейтинг PYPL, на данные с Google Trends и на анализ видео по интересующим меня языкам программирования на YouTube. Теперь же я обращусь к результатам опроса разработчиков, проведённого Stack Overflow в 2020 году. А именно, к данным по языкам программирования, на которых программисты пишут, но не хотят продолжать этим заниматься.


Данные опроса Stack Overflow (источник)

Но надо отметить, что есть много вакансий, требующих знания языков, занимающих высокие позиции в этом антирейтинге. Тем, кто пишет на этих языках, хорошо платят, вознаграждая за их опыт. Эти языки используются во многих компаниях, хотя некоторые компании меняют их на что-то другое.


Зарплаты разработчиков и их связь с языками программирования (источник)

Итоги


Я постоянно наблюдаю за ситуацией в сфере языков программирования. И я считаю, что подобные наблюдения способны принести немалую пользу. Ведь правильный выбор языка способен помочь карьерному росту программиста.

Кроме того, я изучал некоторые из языков, о которых сегодня рассказал. Правда, на практике я ими не пользуюсь. Собственно, надеюсь, что эта статья сможет уберечь других от изучения устаревших языков.

Если же вы пишете на этих языках, если у вас есть крупные проекты и интересная работа, то не думаю, что вам стоит бросаться на поиски чего-то нового. Просто занимайтесь тем, чем занимались, и не обращайте внимания на всякие индикаторы, указывающие на то, что популярность того или иного языка снизилась на 0,2%.

Какими языками программирования вы дополнили бы список умирающих технологий из этой статьи?



Подробнее..
Категории: Блог компании ruvds.com , Программирование , Разработка , Haskell , Perl , Objective c

Перевод Ptpython улучшенный REPL для Python

05.06.2021 14:06:41 | Автор: admin
Возникало ли у вас когда-нибудь желание быстро испытать какую-нибудь свежую идею, прибегнув к интерфейсу командной строки Python, к REPL? Вероятно, если речь идёт об эксперименте буквально с несколькими строками кода, вам просто не захочется создавать для этого новый блокнот Jupyter.

Но в подобной ситуации, возможно, вас не особенно порадует и перспектива использования классической консоли Python, так как она, в отличие от Jupyter Notebook, не поддерживает автодополнение ввода и не умеет работать с документационными строками. В REPL, кроме того, нельзя, после нажатия на Enter, исправлять ошибки в коде.

Что если можно было бы превратить довольно-таки скучную командную строку Python в многофункциональный инструмент, вроде того, запись работы с которым показана ниже?


Продвинутая командная строка Python

Собственно, именно на тех, у кого возникает подобное желание, и ориентирован проект ptpython.

Что такое ptpython?


Ptpython можно назвать улучшенным интерфейсом командной строки Python. Установить его можно так:

pip install ptpython

А для того чтобы его запустить достаточно воспользоваться следующей командой:

ptpython

Возможности по вводу данных


Проверка вводимых данных


Если, работая в классической командной строке Python, допустить ошибку при вводе команды, то, после нажатия на Enter, нельзя вернуться к неправильному коду и его исправить.


Ошибка, допущенная в обычной командной строке Python

Но ptpython позволяет проверить то, что введено с клавиатуры, ещё до нажатия на Enter. На следующем анимированном изображении показано, что пропущенная закрывающая скобка вызывает появление сообщения об ошибке. Эту ошибку можно тут же исправить.


Исправление ошибки при работе в ptpython

Автодополнение ввода, основанное на исторических данных


Если вы когда-нибудь подумывали о том, что при работе с командной строкой Python не помешали бы возможности по автодополнению ввода, основанному на исторических данных, то знайте, что ptpython это поддерживает.


Автодополнение ввода, основанное на исторических данных

Но эта возможность ptpython, по умолчанию, не включена. Правда, для того чтобы включить её, достаточно, воспользовавшись клавишей F2, вызвать меню, в котором, пользуясь клавишами-стрелками, надо найти опцию Auto suggestion и перевести её в состояние on. Для закрытия меню надо нажать на Enter.


Включение автодополнения ввода

После включения опции Auto suggestion у вас должно заработать автодополнение ввода, основанное на истории. Для того чтобы воспользоваться тем, что предлагает ptpython, достаточно нажать клавишу-стрелку Вправо.

Использование подсказок при вводе кода


Если при работе с объектом ввести точку будет выведен список его свойств и методов.


Подсказки, выводимые после ввода точки

Для выбора нужного варианта используются клавиши-стрелки, а после выбора подходящего варианта можно продолжить ввод своего кода.

Вставка данных из истории команд


Посмотреть историю команд можно, нажав клавишу F3. Для того чтобы выделить код, который надо скопировать в рабочую область из панели истории, нужно перейти на соответствующую строку клавишами-стрелками и нажать на клавишу Пробел.

После того, как выбор нужного участка кода завершён, достаточно нажать на Enter и соответствующий код будет вставлен в рабочую область.


Копирование кода из панели истории

Обратите внимание на то, что код в рабочую область будет вставлен в порядке его выполнения.

Режим вставки


Возникало ли у вас когда-нибудь желание отредактировать код, вставленный в командную строку Python? В обычном Python REPL сделать этого нельзя.


Работа в обычной командной строке Python

А ptpython позволяет редактировать вставленный код, доводя его до нужного состояния.


Редактирование вставленного кода в ptpython

Для того чтобы включить режим вставки достаточно нажать на клавишу F6. Когда этот режим активирован код, при нажатии на Enter, выполняться не будет. А после того, как код будет готов к выполнению нужно снова нажать F6 для выключения режима вставки, а потом дважды нажать на Enter.

Возможности по выводу данных


Просмотр сигнатур функций и документационных строк


Ptpython позволяет просматривать сведения о параметрах функций и конструкторов.


Просмотр сведений о конструкторе DataFrame

Ещё можно смотреть документационные строки классов и функций. Для включения этой возможности нужно открыть меню (F2), а потом включить опцию Show docstring.


Включение вывода документационных строк

Теперь можно просматривать документацию по используемым программным конструкциям.


Вывод документации

Выделение парных скобок


Для того чтобы повысить удобство работы со сложными конструкциями, в которых используются скобки, ptpython умеет выделять парные скобки.


Выделение парных скобок

Добавление пустой строки после введённых или выведенных данных


Если нужно улучшить читабельность кода можно сделать так, чтобы после выводимых или вводимых данных автоматически добавлялись бы пустые строки.


Улучшение читабельности кода за счёт пустых строк

Для того чтобы включить эту возможность нужно, вызвав меню клавишей F2, включить опции Blank line after input и Blank line after output.


Включение опций Blank line after input и Blank line after output

Выделение синтаксических конструкций


Ptpython, кроме прочего, поддерживает подсветку синтаксиса.


Подсветка синтаксиса

Для переключения цветовых тем можно воспользоваться клавишей-стрелкой Вправо, нажимая её до тех пор, пока не будет выбрана подходящая тема.

В системе имеется 39 тем. Если, например, вам хочется выбрать такую же цветовую схему, которая используется в Sublime Text знайте, что она имеет код monokai. Этот код нужно ввести в опции меню Code, которую можно найти в разделе Colors.


Настройка темы в меню

Магические команды IPython


Ptpython поддерживает магические команды IPython. Для того чтобы получить доступ к возможностям IPython, нужно воспользоваться командой ptipython.


Возможности IPython


Возможности IPython

Настройка ptpython


Те изменения, которые вносят в настройки ptpython во время работы, исчезают после окончания сеанса работы с программой.

Настройки, которые используются в каждом сеансе, должны быть описаны в файле $XDG_CONFIG_HOME/ptpython/config.py. В Linux путь к нему выглядит как ~/.config/ptpython/config.py.

Вот файл, который содержит все те полезные настройки программы, о которых мы говорили выше.

Итоги


В этом материале мы рассмотрели лишь мои любимые возможности ptpython. А их, на самом деле, гораздо больше. Если ptpython вам понравится, вы, наверняка, найдёте в нём что-то такое, что пригодится именно вам.

Планируете ли вы пользоваться ptpython?


Подробнее..
Категории: Блог компании ruvds.com , Python , Разработка веб-сайтов , Разработка , Perl , Ruvds_перевод , Ptpython , Repl

Перевод Трюки с переменными среды

17.07.2020 08:05:27 | Автор: admin
Интересные переменные среды для загрузки в интерпретаторы скриптовых языков

Вступление


В недавнем хакерском проекте мы получили возможность указывать переменные среды, но не выполняемый процесс. Мы также не могли контролировать содержимое файла на диске, а брутфорс идентификаторов процессов (PID) и файловых дескрипторов не дал интересных результатов, исключив удалённые эксплоиты LD_PRELOAD. К счастью, исполнялся интерпретатор скриптового языка, который позволял нам выполнять произвольные команды, задавая определённые переменные среды. В этом блоге обсуждается, как произвольные команды могут выполняться рядом интерпретаторов скриптового языка при вредоносных переменных среды.

Perl


Беглое чтение раздела ENVIRONMENT справочной страницы perlrun(1) показывает множество переменных среды, достойных изучения. Переменная среды PERL5OPT позволяет задавать параметры командной строки, но ограничивается только принятием параметров CDIMTUWdmtw. К сожалению, это означает отсутствие -e, которая даёт загружать код perl для запуска.

Однако не всё потеряно, как показано в эксплоите для CVE-2016-1531 от Hacker Fantastic. Эксплоит записывает вредоносный модуль perl в файл /tmp/root.pm и предоставляет переменные среды PERL5OPT=-Mroot и PERL5LIB=/ tmp для выполнения произвольного кода. Однако это был эксплоит для локальной уязвимости эскалации привилегий, а общий метод в идеале не должен требовать доступа к файловой системе. Глядя на эксплоит от blasty для того же CVE, он не требовал создания файла, использовал переменные среды PERL5OPT=-d и PERL5DB=system("sh");exit;. Те же переменные были использованы для решения задачи CTF в 2013 году.

Последняя тонкость универсального метода заключается в использовании одной переменной среды вместо двух. @justinsteven обнаружил, что это возможно с помощью PERL5OPT=-M. В то время как для загрузки модуля perl можно использовать либо -m, либо -M, но опция -M позволяет добавлять дополнительный код после имени модуля.

Доказательство концепции


Пример 0: Выполнение произвольного кода с помощью переменной среды против perl, выполняющего пустой скрипт (/dev/null)
$ docker run --env 'PERL5OPT=-Mbase;print(`id`)' perl:5.30.2 perl /dev/nulluid=0(root) gid=0(root) groups=0(root)

Python


Судя по разделу ENVIRONMENT VARIABLES в манах по python(1), PYTHONSTARTUP изначально выглядит как простое решение. Он позволяет указать путь к скрипту Python, который будет выполнен до отображения приглашения в интерактивном режиме. Требование к интерактивному режиму не казалось проблемой, поскольку переменная среды PYTHONINSPECT может использоваться для входа в интерактивный режим, так же как и -i в командной строке. Однако документация для опции -i объясняет, что PYTHONSTARTUP не будет использоваться, когда python запускается со скриптом для выполнения. Это означает, что PYTHONSTARTUP и PYTHONINSPECT не могут быть объединены, а PYTHONSTARTUP имеет эффект только тогда, когда Python REPL немедленно запускается. Это в конечном счете означает, что PYTHONSTARTUP нежизнеспособен, так как не имеет никакого эффекта при выполнении обычного скрипта Python.

Многообещающе выглядели переменные среды PYTHONHOME и PYTHONPATH. Обе позволяют произвольное выполнение кода, но требуют, чтобы вы также могли создавать каталоги и файлы в файловой системе. Возможно, удастся ослабить эти требования с помощью виртуальной файловой системы /proc и/или ZIP-файлов.

Большинство остальных переменных среды просто проверяются на непустую строку, и если да, то включают в целом доброкачественную настройку. Одним из редких исключений является PYTHONWARNINGS.

Работа с помощью PYTHONWARNINGS


В документации для PYTHONWARNINGSговорится, что это эквивалентно указанию параметра -W. Параметр -W используется для управления предупреждениями, чтобы указать предупреждения и как часто их выводить. Полная форма аргумента action:message:category:module:line. Хотя контроль предупреждений не казался многообещающей зацепкой, это быстро изменилось после проверки реализации.

Пример 1: Python-3.8.2/Lib/warnings.py
[...]def _getcategory(category):    if not category:        return Warning    if '.' not in category:        import builtins as m        klass = category    else:        module, _, klass = category.rpartition('.')        try:            m = __import__(module, None, None, [klass])        except ImportError:            raise _OptionError("invalid module name: %r" % (module,)) from None[...]

Этот код показывает, что пока наша указанная категория содержит точку, мы можем запустить импорт произвольного модуля Python.

Следующая проблема в том, что подавляющее большинство модулей из стандартной библиотеки Python при импорте выполняют очень мало кода. Они обычно просто определяют классы, которые будут использоваться позже, и даже когда они предоставляют код для запуска, код обычно защищён проверкой переменной __main__ (чтобы определить, был ли файл импортирован или запущен напрямую).

Неожиданным исключением из этого правила является модуль antigravity. Разработчики Python в 2008 году включили пасхальное яйцо, которое можно вызвать запуском import antigravity. Этот импорт немедленно откроет в вашем браузере комикс xkcd с шуткой, что импорт антигравитации в Python даёт возможность летать.

Что касается того, как модуль antigravity открывает ваш браузер, он использует другой модуль из стандартной библиотеки под названием webbrowser. Этот модуль проверяет ваш PATH для большого разнообразия браузеров, включая mosaic, opera, skipstone, konqueror, chrome, chromium, firefox, links, elinks и lynx. Он также принимает переменную среды BROWSER с указанием, какой процесс выполнить. Процессу в переменной среды нельзя предоставить аргументы, а URL-адрес комикса xkcd является единственным жёстко закодированным аргументом для команды.

Возможность превратить это в выполнение произвольного кода зависит от того, какие другие исполняемые файлы доступны в системе.

Использование Perl для выполнения произвольного кода


Один из подходов заключается в использовании Perl, который обычно установлен в системе и даже доступен в стандартном докеровском образе Python. Однако нельзя использовать бинарник perl сам по себе, потому что первым и единственным аргументом является URL-адрес комикса xkcd. Данный аргумент вызовет ошибку, а процесс завершится без использования переменной среды PERL5OPT.

Пример 2: PERL5OPT не оказывает никакого эффекта, когда URL передаётся в perl
$ docker run -e 'PERL5OPT=-Mbase;print(`id`);exit' perl:5.30.2 perl https://xkcd.com/353/Can't open perl script "https://xkcd.com/353/": No such file or directory

К счастью, когда Perl доступен, также часто доступны сценарии Perl по умолчанию, такие как perldoc и perlthanks. Эти скрипты также будут завершаться с ошибкой и недопустимым аргументом, но ошибка в этом случае происходит позже, чем обработка переменной среды PERL5OPT. Это означает, что вы можете использовать полезную нагрузку переменной среды Perl, подробно описанную ранее в этом блоге.

Пример 3: PERL5OPT работает как положено с perldoc и perlthanks
$ docker run -e 'PERL5OPT=-Mbase;print(`id`);exit' perl:5.30.2 perldoc https://xkcd.com/353/uid=0(root) gid=0(root) groups=0(root)$ run -e 'PERL5OPT=-Mbase;print(`id`);exit' perl:5.30.2 perlthanks https://xkcd.com/353/uid=0(root) gid=0(root) groups=0(root)

Доказательство концепции


Пример 4: Выполнение произвольного кода с использованием нескольких переменных среды с Python 2 и Python 3
$ docker run -e 'PYTHONWARNINGS=all:0:antigravity.x:0:0' -e 'BROWSER=perlthanks' -e 'PERL5OPT=-Mbase;print(`id`);exit;' python:2.7.18 python /dev/nulluid=0(root) gid=0(root) groups=0(root)Invalid -W option ignored: unknown warning category: 'antigravity.x'$ docker run -e 'PYTHONWARNINGS=all:0:antigravity.x:0:0' -e 'BROWSER=perlthanks' -e 'PERL5OPT=-Mbase;print(`id`);exit;' python:3.8.2 python /dev/nulluid=0(root) gid=0(root) groups=0(root)Invalid -W option ignored: unknown warning category: 'antigravity.x'

NodeJS


Михал Бентковски в своём блоге выложил полезную нагрузку для эксплоита Kibana (CVE-2019-7609). Прототип уязвимости с загрязнением был использован для установки произвольных переменных среды, которые приводили к произвольному выполнению команд. Полезная нагрузка от Михала использовала переменную среды NODE_OPTIONS и файловую систему proc, в частности, /proc/self/environ.

Хотя техника Михала творческая и отлично подходит в его случае, она не всегда гарантированно работает и имеет некоторые ограничения, которые было бы неплохо устранить.

Первое ограничение заключается в том, что он использует /proc/self/environ только в том случае, если содержимое можно сделать синтаксически допустимым JavaScript. Для этого необходимо иметь возможность создать переменную среды и заставить её появиться сначала в содержимом файла /proc/self/environ или знать/сбрутить имя переменной среды, которое появится первым, и перезаписать её значение.

Ещё одно ограничение в том, что значение первой переменной среды заканчивается однострочным комментарием (//). Поэтому любой символ новой строки в других переменных среды, скорее всего, вызовет синтаксическую ошибку и предотвратит выполнение полезной нагрузки. Использование многострочных комментариев (/*) не исправит проблему, так как они должны быть закрыты, чтобы быть синтаксически корректными. Поэтому в редких случаях, когда переменная среды содержит символ новой строки, необходимо знать/сбрутить имя переменной среды и перезаписать её значение на новое значение, которое не содержит новой строки.

Устранение этих ограничений оставим в качестве упражнения для читателя.

Доказательство концепции


Пример 5. Выполнения произвольного кода с переменными среды против NodeJS Михала Бентковски
$ docker run -e 'NODE_VERSION=console.log(require("child_process").execSync("id").toString());//' -e 'NODE_OPTIONS=--require /proc/self/environ' node:14.2.0 node /dev/nulluid=0(root) gid=0(root) groups=0(root)

РНР


Если запустить ltrace -e getenv php /dev/null, то вы обнаружите, что PHP использует переменную среды PHPRC. Переменная среды используется при попытке найти и загрузить конфигурационный файл php.ini. Эксплоит от neex для CVE-2019-11043 использует ряд параметров PHP, чтобы добиться выполнения произвольного кода. У Orange Tsai также есть отличный пост о создании собственного эксплоита для того же CVE, который использует немного другой список настроек. Используя эти знания, а также знания, полученные из предыдущей техники NodeJS, и некоторую помощь Брендана Скарвелла, было найдено решение для PHP с двумя переменными среды.

Для этого метода существуют те же ограничения, что и для примеров NodeJS.

Доказательство концепции


Пример 6: Выполнения произвольного кода с переменными среды против PHP
$ docker run -e $'HOSTNAME=1;\nauto_prepend_file=/proc/self/environ\n;<?php die(`id`); ?>' -e 'PHPRC=/proc/self/environ' php:7.3 php /dev/nullHOSTNAME=1;auto_prepend_file=/proc/self/environ;uid=0(root) gid=0(root) groups=0(root)

Ruby


Универсальное решение для Ruby пока не найдено. Ruby действительно принимает переменную среды RUBYOPT для указания параметров командной строки. На man-странице говорится, что RUBYOPT может содержать только -d, -E, -I, -K, -r, -T, -U, -v, -w, -W, --debug, --disable-FEATURE и --enable-FEATURE. Наиболее перспективным вариантом является -r, который заставляет Ruby загружать библиотеку с помощью require. Однако это ограничивается файлами с расширением .rb или .so.

Найденный пример относительно полезного файла .rb это tools/server.rb из gem'а json, который доступен после установки Ruby в системах Fedora. Когда требуется этот файл, запускается веб-сервер, как показано ниже:

Пример 7: Использование переменной среды RUBYOPT для запуска процесса ruby и старта веб-сервера

$ docker run -it --env 'RUBYOPT=-r/usr/share/gems/gems/json-2.3.0/tools/server.rb' fedora:33 /bin/bash -c 'dnf install -y ruby 1>/dev/null; ruby /dev/null'Surf to:http://27dfc3850fbe:6666[2020-06-17 05:43:47] INFO  WEBrick 1.6.0[2020-06-17 05:43:47] INFO  ruby 2.7.1 (2020-03-31) [x86_64-linux][2020-06-17 05:43:47] INFO  WEBrick::HTTPServer#start: pid=28 port=6666

Другой подход в Fedora заключается в том, чтобы использовать тот факт, что /usr/bin/ruby на самом деле является скриптом Bash, который запускает /usr/bin/ruby-mri. Скрипт вызывает функции Bash, которые могут быть перезаписаны переменными среды.

Доказательство концепции


Пример 8: Использование экспортированной функции Bash для выполнения произвольной команды
$ docker run --env 'BASH_FUNC_declare%%=() { id; exit; }' fedora:33 /bin/bash -c 'dnf install ruby -y 1>/dev/null; ruby /dev/null'uid=0(root) gid=0(root) groups=0(root)

Заключение


В этом посте были рассмотрены интересные случаи использования переменных среды, которые могли бы помочь в достижении произвольного выполнения кода с помощью различных интерпретаторов скриптового языка, не записывая файлы на диск. Надеюсь, вам понравилось читать и вам захотелось найти и поделиться улучшенные полезные нагрузки для этих и других скриптовых языков. Если найдёте универсальную технику, которая работает против Ruby, будет очень интересно услышать о ней.
Подробнее..
Категории: Информационная безопасность , Node.js , Python , Php , Perl , Переменные среды , Скриптовые языки

Перевод Угон домена Perl.com

05.03.2021 10:06:07 | Автор: admin

Прим. перев.: в конце января стало известно о том, что один из основных доменов языка программирования Perl Perl.com был угнан. Это вызвало смешанную реакцию в сообществе как любителей языка, так и его противников. Теперь, когда всё уже позади и справедливость восстановлена, один из самых известных сторонников Perl brian d foy рассказал о том, что же произошло и как сообщество добилось положительного исхода событий. Представляем вниманию перевод его заметки.

На неделю мы потеряли контроль над доменом Perl.com. Теперь, когда проблема устранена, можно подробно рассказать о том, что произошло и как мы с этим справились. Инцидент затронул только домен Perl.com, никакие другие ресурсы сообщества не пострадали. Сам сайт никуда не делся, но DNS выдавал другие IP-адреса.

Во-первых, следует отметить, что проблема не связана с продлением домена. Для нас подобная забывчивость была бы даже лучше, поскольку есть так называемый grace period (в течение месяца после expiration его владелец все еще может продлить прим. перев.).

Во-вторых, хочу подчеркнуть, что я всего лишь редактор сайта, который использует домен Perl.com. То есть юридически меня нельзя назвать пострадавшей стороной. Владельцем домена является Tom Christiansen, и если делу будет дан ход, мне или кому-либо другому вовсе не обязательно знать все подробности. Однако я общался со многими людьми, вовлеченными в процесс.

Реакция на инцидент

Думаю, мы проделали неплохую работу со своей децентрализованной реакцией на инцидент, основанной на волонтерах. Поэтому хочу поделиться с вами подробностями. Возможно, у вас уже имеется хороший (или не очень) опыт формального реагирования. Некоторые хитрости в этом процессе помогают избежать лишней головной боли и разочарований.

Ранним утром 27 января Perl NOC (Network Operations Center) в рамках повседневного мониторинга заметил, что с доменом происходит нечто странное. Параллельно пользователи начали жаловаться, что сайт недоступен. По мере обновления записей DNS по всему миру все большее число пользователей сообщали о проблемах. Мы понятия не имели, что происходит и почему.

Я начал негласно собирать информацию об инциденте и написал твит с просьбой о помощи. В тот момент мы не представляли, что именно происходит, а просто наблюдали за последствиями. На ранних стадиях реагирования важно отфильтровать слухи от достоверной информации, и отделить тех, кто что-то знает, от тех, кто просто распространяет слухи. Как обычно, именно пустословы доминируют на информационном поле: ведь их история обычно гораздо более интересная, ведь они могут выдумать все, что угодно, и манипулировать фактами. Поэтому главная задача работать с информацией, а не со спекуляциями, то есть разобраться, что действительно известно, а что лишь догадки.

Я завел Google-документ и пригласил нужных людей. Мы начали заполнять детали, классифицируя их с помощью цвета: зеленого, янтарного, красного. Зеленым помечалась информация, которую мы считали достоверной например, прямое взаимодействие с регистратором; янтарный обозначал непроверенную информацию, которая могла быть правдивой, а красным маркировались недостоверные сведения. Вся информация сопровождалась временем и источником. Первое правило борьбы со слухами запоминать, от кого и когда вы их услышали. Когда это все сведено в документ, любой имеет возможность сравнить имеющуюся у него информацию с общедоступной и понять, является ли она более ценной и актуальной. Иногда информация, которая считалась правдивой, оказывалась недостоверной. Тогда мы вносили изменения в документ.

Также был составлен список дел, и все, кто мог, занялись ими. Например, мы начали проверять другие ресурсы сообщества. Elaine Ashton проверила регистрацию cpan.org (там была странность в контактной информации, но после телефонного разговора с регистратором все оказалось в порядке). Robert Spier, участник Perl NOC, проверил различные сетевые аспекты, хронологию и т.п. Rik Signes вызвался завести закрытый список рассылки на TopicBox (в конце концов, он же CTO). Тонкость здесь в том, чтобы не делать работу, которую может сделать кто-то другой (и часто лучше). Аналогичным образом, если кто-то уже что-то делает, не стоит тратить свое время впустую, переделывая за ним или заново "изобретая велосипед". Децентрализация это классно, но ей необходим координатор. В этом случае координатором стал я, поскольку очень многое вложил в сайт Perl.com. Кроме того, я отлично сработался с Томом, ведь до этого мы целый год трудились над книгой Programming Perl.

Мой твит и комментарии в Reddit привлекли внимание обеих сторон в "регистрационном уравнении", так что на самом старте процесса я смог переговорить как с Network Solutions, так и с Key Systems. Нам очень повезло, что Perl штука довольно известная, а мы с Tom Christiansen, в свою очередь, занимаем не последнее место в сообществе Perl. Первое правило успеха уже быть успешным. Сотрудники различных вовлеченных в процесс организаций предлагали нам свою помощь и давали советы. Увы, другим жертвам повезло меньше, и помощи они не дождались. Все эти организации, вероятно, на определенных этапах своего существования использовали Perl, и с теплотой вспоминали старые добрые времена.

Я в основном отвечал за связь с Томом и помогал ему управляться со всеми игроками. В таких случаях огромный объем работы частенько подавляет людей, и у тех попросту опускаются руки. Тому надо было сосредоточиться на взаимодействии с регистраторами, так что я взял на себя максимум остальной работы, чтобы не отвлекать его.

Почти сразу стало понятно, что когда используешь проблемный домен в качестве своего email-контакта, никто не сможет с тобой связаться в случае трудностей с этим доменом. Больше всего сил мы потратили на подтверждение того, что наши контрагенты это действительно те, за кого они себя выдают. Впрочем, в доменном бизнесе все эти фигуры хорошо известны: ведь они занимаются этим давно и постоянно. Мы позаботились о том, чтобы не перегружать их обращениями от коллег, задающих один и тот же вопрос. Координация контактов помогает избежать избыточности коммуникаций и позволяет ответственным лицам делать свою работу, а не комментировать без конца одни и те же вопросы.

Как только все стороны обменялись актуальной контактной информацией, процесс пошел как по маслу. Мы не были уверены, что все получится, но по мере развития ситуации наша убежденность крепла. Впрочем, уверенность это субъективная информация. Какой смысл говорить о том, что, по вашему мнению, может или должно произойти, если в процесс постоянно вмешиваются всевозможные задержки и заминки?

Поэтому мы переключились на управление публичной информацией и распространение сведений, которыми могли поделиться. Наша цель состояла в том, чтобы заставить людей поверить в достоверность нашей информации. Как технари, мы мечтаем располагать всей доступной информацией, но на самом деле достаточно знать лишь ее необходимый минимум.

Поэтому мы решили публиковать всю актуальную информацию в одном месте в блоге The Perl NOC. Иногда между получением информации и ее публикацией проходило несколько часов мы внимательно проверяли все сведения. Пользователям не было необходимости рыскать по социальным сетям и т.п. в поисках новостей, поскольку все они были собраны в одном месте. Мы по-прежнему транслировали обновления на всех доступных ресурсах, при этом ссылаясь на первоисточник блог NOC. Единый источник информации очень помогает.

Для тех, кто занимался решением проблемы, был разработан краткий отчет о текущей ситуации и тезисы для обсуждения. В основном это были проверенные сведения, которые возможно раскрыть без ущерба для юридического процесса.

Также отслеживались люди и публикации. Кто и какую позицию занимает в той или иной компании, какие журналисты пишут об инциденте, что пишут на форумах. Некоторые участники форумов зависали на них исключительно ради забавы (и это было очевидно), другие публиковали ценные и действенные подробности (то есть были знакомы с ситуацией изнутри). Опять же, для классификации использовалась комбинация зеленый / янтарный / красный.

Это не первое мое "родео", и я взял на себя роль пресс-секретаря. Несмотря на кропотливую работу по проверке всего и вся, многие люди со стороны просто выдумывали всякую ерунду. Что ж, бывает и такое (что вполне предсказуемо). Издательский принцип "Если мать говорит, что любит тебя, найди второй источник" не применим в эпоху Twitter. Часто не нужен даже первый источник.

Важно, чтобы сообщество представлял один человек. Авторы доброй половины "новостных" публикаций не потрудились провести базовые исследования, а у некоторых из них отсутствовала контактная информация (серьезно? Журналист, с которым нельзя связаться?). Некоторые авторы исправили свои материалы, поговорив со мной.

The Register с самого начала выдавал точную информацию, как и Paul Ducklin на сайте Sophos.

Примерно через неделю после изменений на серверах имен, я пришел к заключению, что возврат домена после взлома может растянуться на несколько недель. Поскольку в него были вовлечены разные страны со своими законами и правилами, процесс продвигался гораздо медленнее, чем нам хотелось. В эпоху Интернета "завтра" равносильно "вечности". David Farrell выдвинул идею о переименовании сайта, и мы стали использовать perldotcom.perl.org в качестве временного домена. Robert смог все быстро настроить, и мы классно провели время, анализируя pull request'ы от сообщества. В них пользователи указывали на некоторые моменты, которые мы за'hardcode'или, хотя не должны были (любой человек может предложить PR по любому поводу, имеющему отношение к сайту!). Основой для всей этой работы выступал процесс на базе GitHub, который разработал David (нам приятно получать даже самые незначительные PR от сообщества!).

Затем, в начале февраля, обходными путями я получил надежную (зеленую) информацию о том, что домен вернется к нам через пару дней. Я сперва не поверил, но это действительно произошло! Опять же, нам очень повезло: люди, в сердцах которых Perl занимает особое место, сильно нам помогли. Все стороны понимали, что Perl.com принадлежит Тому, и воплотить это понимание в жизнь было несложно. Владельцам менее известного доменного имени было бы гораздо труднее доказать свои права на него.

Впрочем, с возвращением домена история не закончилась. Пока домен был скомпрометирован, различные продукты в сфере безопасности внесли Perl.com в черный список, а некоторые DNS-серверы занесли его в sinkhole. Мы решили, что постепенно все придет в норму, и отложили празднование возвращения Perl.com до более подходящих времен. Хотелось, чтобы он стал доступен для всех. И, наконец, этот знаменательный момент наступил! Если у кого-то проблемы с Perl.com, пожалуйста, заведите issue, чтобы мы знали, что для некоторой части интернета домен не работает.

Что, по нашему мнению, произошло

В этой части мы поделимся некоторыми догадками (кстати, Perl.com оказался не единственной жертвой). По всей видимости, имела место атака социальной инженерии на Network Solutions, включающая подделку документов и т.п. У Network Solutions нет причин раскрывать мне какие-либо подробности (опять же, я не являюсь потерпевшей стороной), но я поговорил с другим владельцами доменов, и те рассказали мне о наиболее вероятной схеме.

John Berryhill опубликовал в Twitter результаты своего расследования, которое показало, что взлом на самом деле произошел в сентябре. В декабре домен был передан регистратору BizCN, но серверы имен остались прежними. В январе домен вновь был передан другому регистратору Key Systems, GmbH. Подобная задержка помешала выявлению проблемы на ранних этапах, а передача домена от одного регистратора другому значительно осложнила его восстановление.

Обратите внимание на длительную задержку до момента первой передачи. Домен взломан в сентябре, а передача произошла в декабре. Для этого имеется веская причина: 60-дневное правило ICANN. Домен нельзя передать в течение 60 дней после обновления контактной информации. Мы думаем, что регистрация была изменена злоумышленниками одновременно с продлением домена на несколько лет (первоначально домен истекал в 2029 году).

После передачи домена Key Systems в конце января, новый владелец-мошенник выставил его (и другие домены) на продажу на Afternic (рынок доменов). Perl.com можно было купить за 190 тыс. долларов. После запросов The Register домен был снят с продажи.

Некоторые уроки

Очевидно, ситуация неприятная, но ее нельзя назвать уникальной. Домен был зарегистрирован в начале 1990-х, вскоре после этого Tom Christiansen получил над ним контроль, и с тех пор продолжал платить сборы за продление. Как обычно бывает, ничего не менялось "пока гром не грянул". Механизмы вроде двухфакторной авторизации, пожалуй, избавили бы нас от большей части проблем (хотя атаки социальной инженерии умудряются обходить защитные меры).

Я уже упоминал об ошибке, когда для контактов по домену используется сам домен. В результате при возникновении проблемы связаться с владельцем домена невозможно. Поэтому всегда указывайте запасной контакт, не привязанный к домену.

Очень важно вести переговоры с одним и тем же человеком, иначе вы рискуете посеять путаницу из-за многообразия сообщений, даже если в них говорится одно и то же. Также необходимо демонстрировать уверенность и компетентность, чтобы озвучиваемая вами информация воспринималась как достоверная; если разные каналы озвучивают разные послания, риск ошибок возрастает. Perl Foundation настоял на публикации собственного заявления вместо подготовленного нами. Хотя оно было крайне лаконичным, ссылка на блог Perl NOC не работала несколько дней. Не рискуйте понапрасну.

Кроме того, всегда хорошо иметь друзей и поддерживать добрые отношения с людьми, способными помочь. Сотрудники Network Solutions и Key Systems очень помогли нам с восстановлением, как и другие специалисты, поддерживающие работу интернета. Я хотел бы назвать их имена, но уверен, что они предпочтут не афишировать себя и просто делать свою работу.

Текущее состояние дел

Домен Perl.com был благополучно возвращен Tom Christiansen. Ведутся работы над различными мерами, способными предотвратить повторение подобной ситуации. Сайт вернулся к нормальной жизни и стал чуть ярче благодаря всей той помощи, которую мы получили.

В рамках реагирования на инцидент The Perl Foundation Infrastructure Working Group изучила другие важные домены сообщества. Будет проведена соответствующая работа по их защите. Желающие помочь могут связаться с ними.

P.S. от переводчика

Читайте также в нашем блоге:

Подробнее..
Категории: Информационная безопасность , Сообщество , Open source , Dns , Блог компании флант , Perl

Насколько вам наплевать на фичи последней версии языка?

24.05.2021 00:09:13 | Автор: admin

Многие на собеседованиях любят гонять по последним фичам языка. У меня это всегда вызывало недоумение, во всяком случае в сфере веб-разработки. На фронтенде ты смотришь CanIUse(или сношаешься с полифиллами), а на бэкенде ты смотришь на шаблоны vps/vds, которые предоставляют хостеры и прикидываешь когда же в них появятся нужные тебе версии языка. И я абсолютно не против развертывания среды выполнения нужной версии, которая будет отличаться от системной, но давайте будем честными с самими собой. Какой процент из вас ориентируется на последнюю доступную версию языка, а не на то что будет на в ближайшие пару лет дано в ощущениях, браузерах и датацентрах. Внимание опрос!

Подробнее..
Категории: Javascript , Ruby , Python , Php , Хостинг , Vps , Perl , Vds

Опрос Насколько вам наплевать на фичи последней версии языка?

24.05.2021 02:21:51 | Автор: admin

Многие на собеседованиях любят гонять по последним фичам языка. У меня это всегда вызывало недоумение, во всяком случае в сфере веб-разработки. На фронтенде ты смотришь CanIUse (или сношаешься с полифиллами), а на бэкенде ты смотришь на шаблоны vps/vds, которые предоставляют хостеры и прикидываешь когда же в них появятся нужные тебе версии языка. И я абсолютно не против развертывания среды выполнения нужной версии, которая будет отличаться от системной, но давайте будем честными с самими собой. Какой процент из вас ориентируется на последнюю доступную версию языка, а не на то что будет на в ближайшие пару лет дано в ощущениях, браузерах и датацентрах. Внимание опрос!

Подробнее..
Категории: Javascript , Ruby , Python , Php , Хостинг , Vps , Perl , Vds

Софтовый датчик присутствия на Linux AP ESP8266

12.01.2021 16:20:24 | Автор: admin

TL;DR

Наблюдение за изменением уровня Wi-Fi сигнала от стационарно расположенных по дому IoT устройств позволяет сделать полностью программный (выделенное железо отсутствует) обьемный датчик движения в квартире, достаточно точно показывающий наличие активно перемещающихся (фактически, не спящих) людей.

Предыстория

Есть обычная "квартира айтишника" с системой "умный дом" на базе Home Assistant:

  • Самодельные выключатели освещения на базе ESP8266 + MSP430

  • Несколько датчиков температуры/влажности, СО2 и качества воздуха.

  • Контроллер вентиляторов в ванной/туалете

  • пара Sonoff Mini для остального.

Общение девайсов между собой - по Wi-Fi + MQTT. Для минимизации влияния низкоскоростных ESP на "рабочую" Wi-Fi сеть - на отдельном Raspberry Pi 3 запущена отдельная Wi-Fi сеть для IoT, на базе стандартного hostapd. В сумме в IoT Wi-Fi сети - 12 устройств.
Там же на RPi запущен MQTT брокер, рядом на "домашнем сервере" - Home Assistant.

Идея

Уровень сигнала Wi-Fi достаточно зависим от наличия и расположения препятствий между точкой доступа и клиентами. Даже открытая/закрытая деревянная межкомнатная дверь может вызвать заметные изменения в RSSI, не говоря уже о прошедшем человеке. При этом, так как сами wi-fi клиенты стационарны - изменения сигнала от других факторов достаточно минимальны.

Если собрать данные о всех подключенных клиентах - скорее всего, их изменение будет достаточно заметным при перемещении людей в помещении, что и позволит реализовать обьемный датчик движения "просто так" - без установки дополнительного железа.

Реализация

Запустив команду iw dev wlan0 station dump, можно получить достаточно детальную информацию по подключенным клиентам:

Station 60:01:94:21:f8:4c (on wlan0)        inactive time:  8000 ms        rx bytes:       11269629        rx packets:     91423        tx bytes:       6159821        tx packets:     70707        tx failed:      0        signal:         -53 [-53] dBm        tx bitrate:     1.0 MBit/s        rx bitrate:     54.0 MBit/s        ...        connected time: 763375 secondsStation 18:fe:34:98:dc:81 (on wlan0)        inactive time:  4000 ms        rx bytes:       11388688        rx packets:     92101        tx bytes:       6143200        tx packets:     70205        tx failed:      39        signal:         -40 [-40] dBm        tx bitrate:     1.0 MBit/s        rx bitrate:     18.0 MBit/s        ...        connected time: 763378 seconds

Значение RSSI ("signal: -40 [-40] dBm") обновляется в реальном времени, и вызывая iw достаточно часто - можно собрать статистику уровня сигнала.

Запуская iw два раза в секунду и усреднив RSSI за минуту - можно получить значения с более высокой точностью:

Уже по этому графику видно что ночью сигнал остается стабильным, а днем отдельные клиенты отклоняются от "спокойного" состояния на +/- 10 dBm. Однако представление результата можно улучшить, посчитав среднеквадратичное отклонения сигнала для всех клиентов от "спокойного" уровня.

Средние значения

Первым вариантом алгоритма было:

  • Собрать статистику по уровням сигналов в отсутствие людей ("базовый уровень")

  • Сохранить базовый уровень в файле конфигурации

  • Посчитать среднеквадратическое отклонение от базового уровня, которое и будет сигналом "обнаружено движение"

После имплементации такого алгоритма оказалось, что базового уровня не существует. После прохода человека по квартире и возврата в первоначальную точку - сигналы стабилизируются, но на других значениях.
Рассмотрим например тот же график в окресностях 4 утра:

Можно заметить ночной поход в ванную в ~4:30. После него сигналы вернулись к стабильности, но некоторые из них - сместились от предыдущих значений. Отсюда можно сделать вывод, что система в целом - метастабильна, и одного фиксированного "состяния покоя" не существует.

Для решения этой проблемы "состояние покоя" тоже нужно считать как среднее - но за значительно более продолжительный промежуток времени.

Финальный алгоритм

  • Раз в 500мс собираем значения RSSI из вывода iw dev wlan0 station dump.
    Сама команда достаточно легковесна, чтобы не нагружать Raspberry Pi выполнением с такой частотой.

  • Для каждого из клиентов считаем скользящее среднее за последние 1024 сэмпла в качестве "базового уровня":

$RSSI = -65; # Значение из iw dev dump$baseline = ($RSSI + 1023 * $baseline) / 1024;

  • Опять же для каждого считаем скользящее среднее за 256 сэмплов по аналогичной формуле в качестве "текущего значения".

  • Итоговый показатель "активность движения в доме" считается как корень из суммы квадратов отклонений "текущего" от "базового" для каждого из wi-fi клиентов.

Результат уже намного более нагляден:

Здесь синий график ("IW Signal Distance") и является среднеквадратическим отклонением. Остальное - индивидуальные отклонения от скользящего среднего.

Эмпирическим путем можно предположить, что значения IW Signal Distance >1 (зеленая горизонталь) соответствуют активности людей в помещении. Но эта граница, скорее всего, будет отличаться для других конфигураций помещения и количества устройств.

Результаты

Система работает в таком виде уже более двух лет, и достаточно надежно показывает активность внутри квартиры, с минимальным влиянием соседей.
Моя реализация алгоритма доступна на гитхабе (http://personeltest.ru/aways/github.com/k-korn/misc-scripts/tree/main/iwmon), но она достаточно специфична (Perl + Zabbix + визуализация в Grafana) - и потому готовым решением "plug and play" все же служить не может.

Подробнее..
Категории: Diy или сделай сам , Умный дом , Беспроводные технологии , Iot , Perl , Raspberrypi , Iwmon

Перевод Как мы боролись с техдолгом, или от 15 000 подключений к базе данных до менее чем 100

28.01.2021 14:21:54 | Автор: admin
Недавно новый сотрудник спросил меня за обедом: Какой у нас техдолг?

Услышав вопрос, я не мог не улыбнуться. Спрашивать инженеров-программистов о техническом долге компании это то же самое, что спрашивать о кредитном рейтинге. Так программисты хотят узнать о сомнительном прошлом компании и о том, с каким багажом из прошлого придётся столкнуться. К техническому багажу нам не привыкать.

Как поставщик облачных услуг, который управляет собственными серверами и оборудованием, мы столкнулись с проблемами, с которыми многие другие стартапы в новую эру облачных вычислений не сталкивались. Эти сложные ситуации в конце концов привели к компромиссу, на который нам пришлось пойти, когда компания только начала работать. И, как известно любой быстрорастущей компании, технические решения, которые вы принимаете на раннем этапе, обычно догоняют вас.

Глядя на нового сотрудника, я глубоко вздохнул и начал: Давай я расскажу о том, как у нас было 15 000 прямых подключений к БД

История, которую я рассказал нашему новому сотруднику, это история крупной технической перестройки DigitalOcean. Работала вся компания, эта работа продолжалась несколько лет и преподала нам много уроков.


Как всё начиналось


С самого начала DigitalOcean была одержима простотой. Стремление к простым и элегантным решениям одна из наших основных ценностей. Это касается не только продуктов, но и технических решений. Более всего этот подход выделялся в первоначальной архитектуре системы.

Как и GitHub, Shopify и Airbnb, DigitalOcean начиналась как приложение Rails в 2011 году. Внутри компании приложение называли Cloud, оно управляло всеми взаимодействиями с пользователем как в интерфейсе пользователя, так и в общедоступном API. Сервису Rails помогали два сервиса Perl: Scheduler и DOBE (DigitalOcean BackEnd). Планировщик планировал и назначал дроплеты гипервизорам, а DOBE отвечал за создание реальных виртуальных машин дроплетов. В то время как Cloud и Scheduler работали как автономные службы, DOBE работал на каждом сервере парка машин.

Cloud, Scheduler, DOBE общались друг с другом не напрямую, а через базу данных MySQL, которая выполняла две роли: хранила данные и была посредником при обмене данными. Все три службы использовали одну таблицу базы данных в качестве очереди сообщений, чтобы передавать информацию.

Каждый раз, когда пользователь создавал новый дроплет, Cloud вставлял новую запись о событии в очередь. Scheduler непрерывно, каждую секунду опрашивал БД на предмет новых событий Droplet и планировал их создание на доступном гипервизоре. Наконец, каждый экземпляр DOBE ждал создания новых запланированных дроплетов и выполнял задачу. Чтобы серверы могли обнаружить любые новые изменения, каждому нужно было опросить базу данных на предмет новых записей в таблице.


Хотя бесконечные циклы и прямое подключение каждого сервера к базе данных могли быть рудиментарными, с точки зрения проектирования системы, это было просто и работало особенно для небольшой технической команды, которая сталкивалась с жёсткими сроками, а пользователей становилось всё больше.

Четыре года очередь сообщений базы данных составляла основу технологического стека DigitalOcean. В это время мы приняли архитектуру микросервисов, для внутреннего трафика заменили HTTPS на gRPC, вместо Perl внутренние сервисы стали писать на Golang. Однако все дороги по-прежнему вели к той самой базе данных MySQL.

Важно отметить, что если код легаси, это не означает, что он не работает и его нужно переписать. У Bloomberg и IBM есть устаревшие сервисы, написанные на Fortran и COBOL, которые приносят доход больше, чем целые компании. С другой стороны, у каждой системы есть предел масштабирования. Мы собирались ударить по нашему.

С 2012 по 2016 год пользовательский трафик DigitalOcean вырос более чем на 10 000 %. Мы добавили больше продуктов в наш каталог и больше сервисов в нашу инфраструктуру. Событий в очереди базы данных стало больше. Повышенный спрос на дроплеты означал, что Scheduler, чтобы назначить их все серверам, работал с превышением штатной нагрузки. И, к сожалению для Scheduler, количество доступных серверов не было постоянным.


Чтобы не отставать от растущего спроса на дроплеты, мы добавляли всё больше и больше серверов для обработки трафика. Каждый новый гипервизор означал еще одно постоянное соединение с базой данных. К началу 2016 года у базы было более 15 000 прямых подключений, и каждое запрашивало новые события через одну-пять секунд. Если и этого было недостаточно, то SQL-запрос, который каждый гипервизор использовал для получения новых событий дроплет, также стал сложнее. Он превратился в колосс из более чем 150 строк и JOIN в 18 таблиц. Этот код впечатлял настолько же, сколько рискованно и трудно было его поддерживать.

Не удивительно, что именно тогда система треснула. Единая точка отказа с тысячами зависимостей, которые боролись за общие ресурсы, время от времени неизбежно обращалась в хаос. Таблицы блокировались и запросы не выполнялись, и это приводило к сбоям, падала производительность.

Из-за тесной связи в системе не было чёткого или простого решения проблемы. Cloud, Schedule и DOBE оказались узкими местами. Патчи только одного или двух компонентов сместили бы нагрузку на оставшиеся узкие места. Поэтому после долгих раздумий инженеры разработали план исправления из трёх пунктов:

  1. Уменьшить количество прямых подключений к базе данных.
  2. Переписать алгоритм ранжирования Scheduler, чтобы повысить доступность этого сервиса.
  3. Освободить БД от ответственности за очередь сообщений.

Переписываем код: начало


Чтобы справиться с зависимостями базы данных, инженеры DigitalOcean создали Event Router. Маршрутизатор событий служил региональным прокси-сервером, который опрашивал базу данных от имени каждого экземпляра DOBE в каждом центре обработки данных. Вместо тысяч серверов, каждый из которых запрашивает базу данных, осталась только горстка выполняющих запрос прокси. Каждый прокси-сервер маршрутизатора событий будет извлекать все активные события в определённом регионе и делегировать каждое событие соответствующему гипервизору. Event Router также разбил гигантский опрашивающий запрос на запросы, которые проще поддерживать.


Когда Event Router был запущен, он сократил количество подключений к базе данных с более чем 15 000 до менее 100.

Затем инженеры нацелились на планировщика. Как упоминалось ранее, Scheduler был сценарием Perl и определял, в каком гипервизоре разместить дроплет. Делалось это с помощью серии запросов, чтобы сортировать и ранжировать серверы. Всякий раз, когда пользователь создаёт дроплет, планировщик обновляет строку таблицы на лучшую машину.

Хотя это звучит достаточно просто, Scheduler имел несколько недостатков. Его логика была сложной, работать с ней было непросто. Он был однопоточным, и его производительность снижалась во время пиковой нагрузки. Наконец, был только один экземпляр Scheduler и он должен был обслуживать весь парк. Это узкое место было неизбежным. Чтобы решить эти проблемы, команда инженеров разработала Scheduler V2.

В обновлённом планировщике переработали всю систему ранжирования. Вместо того чтобы запрашивать у базы данных показатели сервера, планировщик агрегировал их из гипервизоров и хранил в собственной базе данных. Кроме того, команда Scheduler применила параллелизм и репликацию, чтобы их новый сервис под нагрузкой оставался производительным.

Event Router и Scheduler v2 были большими достижениями, они устраняли многие недостатки архитектуры. Но даже с ними имела место большая препона [прим. перев. это несколько удивительно, но слово препона женского рода]. К началу 2017 года централизованная очередь сообщений MySQL всё ещё использовалась. Она обрабатывала до 400 000 новых записей в день и обновлялась 20 раз в секунду.

К сожалению, удалить очередь сообщений из базы данных было нелегко. Сначала инженеры запретили сервисам прямой доступ к базе. База нуждалась в дополнительном уровне абстракции. Слою также требовался API, чтобы агрегировать и выполнять запросы от его имени. Если какой-либо сервис захочет создать новое событие, ему нужно будет сделать это через API. Так родился Harpoon.

Достичь согласия труднее, чем вы думаете



Однако создать интерфейс очереди сообщений было легко. Труднее оказалось достичь согласия с другими командами. Интеграция с Harpoon означала, что командам пришлось бы отказываться от доступа к базе данных, переписывать куски своего кода и, в конечном счёте, изменить свои привычки. Это было нелегко.

Команда за командой и сервис за сервисом инженеры Harpoon смогли перенести всю кодовую базу на свою новую платформу. На это ушёл почти год, но к концу 2017 года Harpoon стал единственным издателем очереди сообщений базы данных.

Началась настоящая работа. Полный контроль над системой событий означал, что с Harpoon мы получили свободу переосмыслить рабочий процесс дроплета.

Первой задачей Harpoon было взять на себя обязанности по очереди сообщений из базы данных. Для этого Harpoon создал собственную внутреннюю очередь сообщений, состоящую из RabbitMQ и асинхронных воркеров. Пока Harpoon отправлял новые события в очередь с одной стороны, воркеры забирали их с другой стороны. А поскольку RabbitMQ заменил очередь базы данных, воркеры могли напрямую общаться с планировщиком и маршрутизатором событий. Таким образом, вместо того чтобы Scheduler V2 и Event Router опрашивали базу данных на предмет изменений, Harpoon отправлял обновления к ним напрямую. На момент написания этой статьи, в 2019 году, архитектура событий дроплет всё ещё работает.


Прогресс DigitalOcean


За последние семь лет мы выросли из группы в гараже до признанного провайдера облачных сервисов, которым являемся сегодня. Как и другие технологические компании, которые занимались переходной экономикой, мы постоянно работаем с устаревшим кодом и техническим долгом. Будь то дробление монолитов, создание мультирегиональных сервисов или устранение единых точек отказа, мы, инженеры, всегда работаем, чтобы создать простые и элегантные решения. Я надеюсь, что эта история окажется полезной для других разработчиков, которые ломают голову над техническим долгом.


Другие профессии и курсы
ПРОФЕССИИ


КУРС



Подробнее..
Категории: Программирование , Управление проектом , Разработка , Блог компании skillfactory , Go , Техдолг , Серверная оптимизация , Perl , Skillfactory

Перевод Сервер в одну строку на 17 языках

16.05.2021 16:07:51 | Автор: admin
Каждая из этих команд будет запускать специальный статический http-сервер в вашем текущем (или указанном) каталоге, доступном по адресу http://localhost:8000. Используйте эту силу с умом.

Python 2.x


$ python -m SimpleHTTPServer 8000


Python 3.x


$ python -m http.server 8000


Twisted (Python)


$ twistd -n web -p 8000 --path .


Или:

$ python -c 'from twisted.web.server import Site; from twisted.web.static import File; from twisted.internet import reactor; reactor.listenTCP(8000, Site(File("."))); reactor.run()'

В зависимости от Twisted.

Ruby


$ ruby -rwebrick -e'WEBrick::HTTPServer.new(:Port => 8000, :DocumentRoot => Dir.pwd).start'


Ruby 1.9.2+


$ ruby -run -ehttpd . -p8000


adsf (Ruby)


$ gem install adsf   # install dependency$ adsf -p 8000


Sinatra (Ruby)


$ gem install sinatra   # install dependency$ ruby -rsinatra -e'set :public_folder, "."; set :port, 8000'


Perl


$ cpan HTTP::Server::Brick   # install dependency$ perl -MHTTP::Server::Brick -e '$s=HTTP::Server::Brick->new(port=>8000); $s->mount("/"=>{path=>"."}); $s->start
'

Plack (Perl)


$ cpan Plack   # install dependency$ plackup -MPlack::App::Directory -e 'Plack::App::Directory->new(root=>".");' -p 8000


Mojolicious (Perl)


$ cpan Mojolicious::Lite   # install dependency$ perl -MMojolicious::Lite -MCwd -e 'app->static->paths->[0]=getcwd; app->start' daemon -l http://*:8000


http-server (Node.js)


$ npm install -g http-server   # install dependency$ http-server -p 8000


Примечание: этот сервер делает забавные вещи с relative paths. Например, если у вас есть файл /tests/index.html, он загрузит index.html, если вы перейдете в /test, но будет обрабатывать относительные пути, как если бы они исходили из /.

node-static (Node.js)


$ npm install -g node-static   # install dependency$ static -p 8000


PHP (>= 5.4)


$ php -S 127.0.0.1:8000


Erlang


$ erl -s inets -eval 'inets:start(httpd,[{server_name,"NAME"},{document_root, "."},{server_root, "."},{port, 8000},{mime_types,[{"html","text/html"},{"htm","text/html"},{"js","text/javascript"},{"css","text/css"},{"gif","image/gif"},{"jpg","image/jpeg"},{"jpeg","image/jpeg"},{"png","image/png"}]}]).'


busybox httpd


$ busybox httpd -f -p 8000


webfs


$ webfsd -F -p 8000


В зависимости от webfs.

IIS Express


C:\> "C:\Program Files (x86)\IIS Express\iisexpress.exe" /path:C:\MyWeb /port:8000


В зависимости от IIS Express.

Подробнее..
Категории: Программирование , Node.js , Ruby , Python , Сервер , Perl

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru