Комментарии 43
А где остальные 4?
По сути всё, что вы делаете тут — это запускаете стандартный http.server одним способом. Я уж грешным делом подумал, что тут и systemd будет, и nginx unit, и синие киты.
То есть, если дать ему 102 в данном случае, а потом другое устройство получит 102 по DHCP, то как получить доступ?
Статический лучше выдавать за пределами DHCP диапазона.
P.S.: Я обычно стараюсь таблицу статических адресов держать на самом маршрутизаторе, что бы было в одном месте, но в данном случае это уже не так важно.
Гораздо правильнее будет в роутере создать статическую привязку «MAC address = IP Adress».
По какой-либо причине изменится IP пространство на интерфейсе устройства ( подсеть ) — будет будет увлекательный квест по получению доступа к ней.
Круто. Спасибо большое.
Есть вопрос по стабильности. Если нужно чтобы http был доступен 24х7 хватит и такой реализации? Что будбет если устройство начнут буртфорсить?
2-3 месяца домашний мини-сервер у меня как-то работал, дольше нужды не было. Электронные часы на Raspberry Pi проработали пару лет, потом сдохла SD-карта (хотя её можно было бы сделать read-only, тогда проблем бы не было).
Если задачи ресурсоемкие, для Raspberry Pi обязателен хороший блок питания и радиатор на проц, иначе виснет от перегрева.
не советую использовать Google DNS в качестве резервного, многие ресурсы подолгу остаются недоступными после изменений в зонах, особенно часто вообще не резолвятся в случае добавления субдоменов, гораздо лучше работают DNS сервера от Yandex
Самое интересное — включение самоделки в автозагрузку, назначение прав, запись/незапись логов… про это ни слова.
Что произойдет, если внутри есть некий неатомарный ногодрыг (опрос внешнего датчика к примеру) и веб-сервер при обработке 2 почти одновременно пришедших запросов выполнит эти действия параллельно в 2 потоках? Это же raspberry, туда обычно подключают разную периферию
Кому-то и этого много, кому-то этого откровенно мало (вопросы для рассмотрения iig поддержу).
К примеру, в статье нет примеров с WSGI, который считается более «зрелым» методом, потому что все проблемы с безопасностью, брутфорсом и тому подобным берут на себя решения на базе Apache/Nginx веб-серверов, а не решения для разработчиков на базе Питона, где вопросы с безопасностью выставления такого в Интернет вообще решено было оставить за скобками статьи.
Просто уровень статьи вызывает вопросы
Уровень расчитан на начинающих, это прямо указано в первом же абзаце.
В вопросах ничего плохого нет, добавлю в wish-list.
Потому что если представить себе, что RPi купил обычный человек (имевший опыт только с Windows), то работа с Cron'ом или тем более systemd для добавления старта своей программы по target'у потребует гуглежа и многочисленных неудачных попыток.
Просто вписать можно, но не факт, что все заработает, так как окружение при запуске из rc.local совсем другое. А если ваш скрипт из rc.local запустится до того, как сетевые интерфейсы поднимутся? И текущая папка другая будет? И пользователя хорошо бы сменить, чтобы от рута не запускать ваш сервер. Короче, дьявол в детялах, и, кстати, по-моему, с systemd это как раз можно сделать унифицированно, без необходимости городить свои велосипеды.
Есть краткий туториал по разным способам запуска тут кстати: www.dexterindustries.com/howto/run-a-program-on-your-raspberry-pi-at-startup
Root обычно по-любому нужен если нужен GPIO и работа с периферией (либо надо разделять сервисы на 2 разных).
Не обязателен, обычно по-умолчанию в таких дистрибутивах выделяются специальные группы gpio,i2c,spi… И даже в том случае, если ваша программа работает напрямую с памятью, то часть ее все равно выделена в /dev/gpiomem на которую даются права пользователям из группы gpio.
raspberrypi.stackexchange.com/questions/40105/access-gpio-pins-without-root-no-access-to-dev-mem-try-running-as-root
Как показала статистика опроса, 85% читателей все же нашли что-то полезное, хотя я вполне понимаю что для профи такие статьи читать может быть скучно (так ведь никто и не заставляет, в первом абзаце сразу написано что текст для начинающих).
В статье ожидается увидеть что-то интересное. Либо из теории, либо необычное know-how, либо изящное решение практической задачи. Но helloworld это слабовато.
Но да, как я и написал в самом начале, это был эксперимент, посмотреть по оценкам насколько такие статьи востребованы. Нет значит нет, не вопрос, буду смотреть статистику в конце 3х дней голосования.
Кстати скажу по секрету, что недовольные, ставящие минусы, есть везде, независимо от уровня статьи, хоть про hello world, хоть про нейронные сети, хоть про декодирование RDS.
Интересно в основном для рид онли участников, имхо. Но в формировании рейтинга таковые не участвуют.
ну вы же указываете заранее, что этот текст предназначен для новичков. Заранее озвучиваете проблемматику. Я не понимаю "умников", которые либо не читают вступление либо читают, но намеренно заходят в комментарии вставить своё "веское фи!".
Славабогу, есть более грамотные/опытные специалисты, которые просто добавляют или корректируют описанное. От этого статья становится ещё полезней.
Пожалуйста, пишите ещё. И про Пайтон, и про Распбери.
Для быстрого и энергоэффективного HTTP-сервера лучше взять uWSGI — он может без проблем смотреть "в мир" и обладает огромной гибкостью конфигурации, а в случае необходимости можно подключить один из WSGI-совместимых фреймворков. Его также можно подружить с aiohttp поверх uvloop — получите удобный и высококонкуррентный сервер на современных async/await, а uWSGI будет просто выступать мастер-процессом, контролирующим рабочие процессы.
А так, интересно было бы еще узнать, какую нагрузку (сколько клиентов) выдержат сервера.
Много вопросов/комментариев на тему: «не написано вот об этом». Мне как новичку, всегда хочется увидеть минимально работающий код, чтобы понять что именно делает каждая строчка в коде. В полноценной программе сложнее понять, что отвечает за основной функционал, а что отвечает за обработку ошибок, логгирование и т.д.
+DDNS не забудьте.
По моему мнению, если это планируется выставлять в инет, то нужно:
1. Снять за пару баксов в месяц VPS. И разместить на нем web интерфейс, сервер MQTT и VPN-сервер.
2. Клиентскую часть на raspberry pi реализовать в виде клиента mqtt. vpn поднимать при подъеме сети.
Если устройство одно в своем роде, то mqtt-сервер можно оставить на стороне raspberry pi, тогда можно будет написать приложение для android для руления по локальной сети без интернета.
Возможен пункт один без vpn, но тогда придется еще и с шифрованием mqtt заморочиться. И vpn удобнее в плане доступа к малине для диагностики.
Это достаточно удобно, если нужно открыть удаленный доступ к каким-либо файлам с минимумом затраченных сил.
Достаточно удобно — это подключиться по scp. А входить по ssh, затем поднимать сервер, затем заходить на сервер, а после убивать процесс — это не достаточно удобно.
С другой стороны, это ведь всего лишь пример использования, надеюсь)
5 способов сделать Python-сервер на Raspberry Pi. Часть 1