Feb. 20th, 2016
А вот у меня теперь вместе с новым сервером есть /64 сетка IPv6. В смысле, globally routable. Попробовать, что-ли какую-нибудь пользу из нее извлечь? Например, пробросить по openvpn домой, чтобы забыть про NAT-ы как про страшный сон?
Или каждому из name-based веб-сайтов отдельный адрес навести?
(адресов, конечно, хватит и на то, и на другое. Можно, скажем, /96 отдать на vpn, /96 на сайты и еще 4 миллиарда /96 останется).
Вопрос в том, а есть ли в этом какой-нибудь смысл?
Или каждому из name-based веб-сайтов отдельный адрес навести?
(адресов, конечно, хватит и на то, и на другое. Можно, скажем, /96 отдать на vpn, /96 на сайты и еще 4 миллиарда /96 останется).
Вопрос в том, а есть ли в этом какой-нибудь смысл?
Руками водить буду.
Feb. 20th, 2016 05:24 pmТеперь моя должность официально называется "Руководитель релизной группы". Последний раз я занимал руководящую должность ровно 13 лет назад - в феврале 2003 года. Должность, правда, была более громкая, "Технический директор".
К счастью, нынешняя должность подразумевает в основном тактическое руководство. Далеко идущие архитектурные решения принимаю не я. Правда, мне иногда приходится добиваться того, чтобы решение было всё же принято. Хоть какое-нибудь.
К счастью, нынешняя должность подразумевает в основном тактическое руководство. Далеко идущие архитектурные решения принимаю не я. Правда, мне иногда приходится добиваться того, чтобы решение было всё же принято. Хоть какое-нибудь.
Без граблей переезд сервера не обошелся
Feb. 20th, 2016 08:04 pmПерестал работать dav.
Возвращает 405 Method Not Allowed в директории, где явно прописано DAV on.
Как выяснилось, в Apache 2.4 кто-то додумался, что DAV (в смысле методы PROPFIND, OPTIONS и иже с ними) должны быть разрешены только там, где DirectoryIndex disabled.
Я даже понимаю, какая извращенная security-логика за этим стояла. Ну примерно такая же как за стриптизом в аэропортах.
Но вот раньше можно было DAV-клиентом редактировать сайт по тому же URL по которому его смотреть в браузере. При этом в браузере ты видел сайт, а в DAV-клиенте - список файлов (он их методом PROPFIND смотрит, а не GET).
Теперь почему-то разработчики Apache настаивают что по той URL, по которой можно использовать DAV-клиент, браузер тоже должен видеть пачку файлов.
Раньше соответствующий кусок конфига апача выглядел как
Теперь приходится делать вот так:
И, соответственно, браузер натравливаем на https://my.server.domain, а кадавра - на
https://my.server.domain/dav
Хотя казалось бы разделение на URL для редактирования и URL для просмотра имело смысл тогда, когда статические сайты смотрели по http, а не в эпоху всеобщего https.
Теперь вопрос - а какой юз-кейс остался для директивы LimitExcept?
Возвращает 405 Method Not Allowed в директории, где явно прописано DAV on.
Как выяснилось, в Apache 2.4 кто-то додумался, что DAV (в смысле методы PROPFIND, OPTIONS и иже с ними) должны быть разрешены только там, где DirectoryIndex disabled.
Я даже понимаю, какая извращенная security-логика за этим стояла. Ну примерно такая же как за стриптизом в аэропортах.
Но вот раньше можно было DAV-клиентом редактировать сайт по тому же URL по которому его смотреть в браузере. При этом в браузере ты видел сайт, а в DAV-клиенте - список файлов (он их методом PROPFIND смотрит, а не GET).
Теперь почему-то разработчики Apache настаивают что по той URL, по которой можно использовать DAV-клиент, браузер тоже должен видеть пачку файлов.
Раньше соответствующий кусок конфига апача выглядел как
DocumentRoot /srv/www <Directory /srv/www> Dav On AuthType Basic AuthName DAV AuthUserFile /etc/apache2/dav.passwd <LimitExcept GET OPTIONS> require valid-user </LimitExcept> </Directory>
Теперь приходится делать вот так:
DocumentRoot /srv/www Alias /dav /srv/www <Directory /srv/www> Require all granted </Directory> <Location /dav> DirectoryIndex disabled Dav On AuthType Basic AuthName DAV AuthUserFile /etc/apache2/dav.passwd Require valid-user </Location>
И, соответственно, браузер натравливаем на https://my.server.domain, а кадавра - на
https://my.server.domain/dav
Хотя казалось бы разделение на URL для редактирования и URL для просмотра имело смысл тогда, когда статические сайты смотрели по http, а не в эпоху всеобщего https.
Теперь вопрос - а какой юз-кейс остался для директивы LimitExcept?