Несколько разверну заметку (1)
Казалось бы, полное дублирование оборудования, дорогие СХД, дорогие и быстрые технологии... И при этом оплата только по потреблению. Казалось бы, рай. Про настоящие и "маркетинговые" облака напишу в другой раз.
С момента зарождения облаков прошло уже несколько лет, появились отзывы.. И стало понятно, что у облаков тоже есть проблемы, просто эти проблемы другие. Что может быть с реальным сервером? Пропало питание, сгорел процессор, пробило память, выгорел порт в свиче, посыпался жесткий диск... 90% проблем касаются чисто технической стороны, подлежат предсказанию и принятию мер заранее. А также требуют обслуживания именно как оборудование.
В облаках проблемы другие. В основном это проблемы с СХД, потери связности, а также очень много - "человеческий фактор". Хороший пример -- clodo (линки ниже).
Плюс у облаков есть ряд проблем, которые все любят "опровергать", и которые на практике только многократно подтверждаются. (та же безопасность и linode), и одна из реальных главных проблем честного облака - крайне сложно предсказать расходы. День ддоса - и весь бюджет на 3 месяца вперёд съеден.
По всем ссылкам также читать комменты.
Selectel
2 облачные системы, спб-1 и спб-2. В спб-1 периодически выпадала СХД, ввели СПб-2 со своими косяками и багами. Главное отличие спб-2 в том, что там уже не 1 СХД, а несколько.
Проблемы есть, но в виде резерва нас оно устраивает полностью + поддержка масштабирования памяти (увы, от мин до макс не более х8, например 256мб-1гб). Самым дорогим ресурсом для нас выходит всё-таки диск, и это единственное, что масштабируется напильником и остановкой сервера, и оплата за выделение места + потребление иопс. В остальном настоящее облако.
Зимой (2011-2012) была проблема с тем, что их облако просто исчерпало лимиты масштабируемости, поэтому создание машин было приостановлено, и потом запущена система спб-2.
Прощай, Selectel
в комментах
Опять авария в облаке Selectel… Доколе?
Clodo
Вроде мегасистема с хранилищем на infiniband, на практике весьма проблемный.
Есть несколько ДЦ, в том числе в оверсан-меркурий, который даёт своё облако Scalaxy
Приключения с Clodo: про земной и заоблачный подход к работе
Clodo.ru и очередное загадочное падение
CLODO — опять лежим или нужно предупреждать заранее
Scalaxy
Особо не изучали: по отзывам, не очень стабильны и весьма дорогие.
О проблемах:
Облако cannot be read
Amazon
"Эталон" облаков, хотя он менее облачный чем даже селектел и представляет из себя просто виртуальную машину (VDS) с автомиграцией на новую ноду в случае чего. Диски тоже, оплата не за реально занятое место (EBS которые), а за выделенное место. Плюс все операции платные, хоть и крайне дешёвые. Но даже в таком виде есть знатные падения.
Рассказ о том, как молния «убила» облако Amazon. По отзывам, простой "супер надёжной системы с 99.9999% (вроде)" надёжностью составил порядка 5 суток.
Есть проблемы и помельче.
"Прямо как я недавно свалил со Scalaxy. Как раз-таки на Selectel. Имхо, так вечно бегать можно. У моего друга подобная неприятность случалась на AWS. Подумать только, сам Amazon, с их то ценами… Амазон, конечно, сам выслал нотификацию о проблеме, и предлагал компенсацию — но потерянная машина была просто тестовой средой, представляющей из себя просто свежеустановленный Debian с FTP+Nginx."
http://habrahabr.ru/post/145647/
"как человек, который амазон пользовал, скажу — там далеко не радужно.
и если виртуалка падает — амазон предлагает запустить новую.
диски надо? используйте persistent. ах, вы не подключали его? извините.
ах подключали, и не доступно? поднимайте snapshot.
ах, вы его не делали? извините, сами дураки.
ах, они не доступны? извините, или подождите и может станет доступным, или сами дураки что снапшоты не лили в другую зону."
http://habrahabr.ru/post/145112/
Rackspace
Считается конкурентом амазону, тоже весьма дорогим. Ссылками возможно дополню позднее.
Jira
У нас не сильно известен, но тут за славный факап "We've completely lost all your data":
"Проблемы случаются не только в России, перевел среду разработки на облачный хостинг: Task Management, Issue Tracker, Subversion, Builds, Wiki. На прошлой неделе в четверг у них все свалилось, к выходным обещали починить. В понедельник прислали письмо: We've completely lost all your data. хостинг к слову в Англии Jira.com"
http://habrahabr.ru/post/143056/#comment_4793925
Итог
Облака могут быть хороши, особенно на старте. Но они же могут съесть все бюджеты при любой ошибке или ддосе. И если с реальной железкой можно защититься, задублировав почти всё, то с облаками надо тоже дублироваться, но уже в другое облако, в другую страну, и лучше вообще другой компании. А также всегда делать бэкапы. Облако - не панацея, и не спасёт от умышленного удаления данных с автоматическим дублированием этого по всем зеркалам.
"3) облачная виртуализация — всего-лишь способ добиться высокой плотности размещения виртуалок на физике. Удобно для хостера, но никак не панацея для клиента."
http://habrahabr.ru/post/120303/#comment_3943417
По мере изучения отзывов стали попадаться вещи вроде "лежим 10 часов... уже 18 часов.. Потеряны деньги и репутация!". А можно вспомнить сбои в любимом всеми амазоне, где были падения на 5 дней. И небольшой вопрос тем, кто потом плачется про огромные потери: А что сделали лично ВЫ, чтобы не допустить этих самых простоев? "Ну вот сейчас всё поднимется, мы заберём проект, бэкапы и уйдём к другим". И тут уместно вспомнить клиентов макхоста, которым отдавали их сайты по 3 месяца.. hosting.ua, у которого ряд серверов просто сгорел, с данными.. Особенно смешно смотрятся фразы "подорвана репутация одного проекта, которую не за какие деньги теперь не восстановить, я делал компенсации и бонусы сколько мог своим пользователям за каждое ваше падение. Что мне теперь делать не представляю.". Видимо, теперь человек представляет как минимум 1 необходимое действие: бэкапы. И минимум в 2 места, а лучше в 3-4. Предполагаю, что после этого такие люди всё-таки начнут делать бэкапы. А у нас уже несколько лет для таких критичных сайтов есть ещё полная копия в горячем резерве, с репликацией баз master-slave с быстрым переключением днс на новое место. А для минимизации расходов - первое место свои железки, а второе как раз облака. И когда в очередной раз облака отваливаются - ничего страшного, это только зеркало. Ну и бэкапы в несколько мест, включая амазон.
вторник, 17 июля 2012 г.
понедельник, 16 июля 2012 г.
<sys-apps/sysvinit-2.88-r3 ("<sys-apps/sysvinit-2.88-r3" is blocking sys-apps/util-linux-2.20.1-r1)
При попытке обновления однажды вылезает
# emerge -p --update --deep --newuse world
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild U ] sys-libs/glibc-2.14.1-r3 [2.13-r4]
[ebuild R ] sys-devel/gettext-0.18.1.1-r1 USE="-git*"
[ebuild R ] sys-devel/binutils-2.21.1-r1 USE="cxx%*"
[ebuild U ] sys-devel/gcc-4.5.3-r2 [4.5.3-r1]
[ebuild R ] sys-apps/busybox-1.19.3-r1 USE="-livecd%"
[ebuild R ] sys-apps/portage-2.1.10.49 USE="(-pypy1_9) (-pypy1_8%)"
[ebuild U ] sys-apps/util-linux-2.20.1-r1 [2.19.1-r1] USE="-ddate% -static-libs%"
[ebuild U ] sys-apps/sysvinit-2.88-r3 [2.88-r2]
[blocks b ]
При попытке обновить что-либо из заблокированного ничего не получится... Делать надо так:
# emerge --update sysvinit util-linux
# emerge -p --update --deep --newuse world
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild U ] sys-libs/glibc-2.14.1-r3 [2.13-r4]
[ebuild R ] sys-devel/gettext-0.18.1.1-r1 USE="-git*"
[ebuild R ] sys-devel/binutils-2.21.1-r1 USE="cxx%*"
[ebuild U ] sys-devel/gcc-4.5.3-r2 [4.5.3-r1]
[ebuild R ] sys-apps/busybox-1.19.3-r1 USE="-livecd%"
[ebuild R ] sys-apps/portage-2.1.10.49 USE="(-pypy1_9) (-pypy1_8%)"
[ebuild U ] sys-apps/util-linux-2.20.1-r1 [2.19.1-r1] USE="-ddate% -static-libs%"
[ebuild U ] sys-apps/sysvinit-2.88-r3 [2.88-r2]
[blocks b ]
При попытке обновить что-либо из заблокированного ничего не получится... Делать надо так:
# emerge --update sysvinit util-linux
пятница, 13 июля 2012 г.
Как стать микрохостером
Для начала, надо определиться с видом деятельности - сдавать оборудование, vds, просто хостить сайты..
Сразу оговоримся, что услуг связи и криптования (vpn) не предоставляем, это отдельный набор документов и долгое общение с ФСБ.
Чтобы просто перепродавать чужие услуги, надо стать хотя бы ИП и стать агентом, указывая, чьи услуги продаются.
Также чтобы просто сдавать чужое оборудование, в виде целых железок, тоже лицензий не надо.
А вот если сдавать услугу (хостинг сайтов, вдс-ов итд) - это уже подпадает под категорию "хостер".
В идеале, хостер - юр лицо, с сертификатами на телематику, своим сданным узлом связи, с разрешением на эксплуатацию в Роскомнадзоре (1)
Для начала, что надо.
Нужна ли лицензия хостеру? (2)
Сдача узла связи для хостинговых компаний
На своё оборудование ССС обязателен. Сертификаты соответствия - оборудование должно быть сертифицировано для оказания услуг связи.
Получать ли лицензию на телематику - вопрос очень спорный, и по ссылкам (например (2)) ясности не добавится. Так что телематику лучше получить:
Без лицензии -- статья 171 уголовного кодекса; с лицензией без сданного узла связи - штраф до 20 тыс. руб. в соответствии с КоАП.
http://forum.hostobzor.ru/lofiversion/index.php/t8585.html
Вот узел связи во многих случаях получается можно и не сдавать, пока обороты не превысят 5-10 млн в год - закрыть-то можно легко, а вот денег состричь уже не сильно выйдет. А если будет именно указание закрыть - и наличие всех документов не поможет. Хотя при хороших оборотах лучше всё-таки озаботиться всеми лицензиями.
Сразу оговоримся, что услуг связи и криптования (vpn) не предоставляем, это отдельный набор документов и долгое общение с ФСБ.
Чтобы просто перепродавать чужие услуги, надо стать хотя бы ИП и стать агентом, указывая, чьи услуги продаются.
Также чтобы просто сдавать чужое оборудование, в виде целых железок, тоже лицензий не надо.
А вот если сдавать услугу (хостинг сайтов, вдс-ов итд) - это уже подпадает под категорию "хостер".
В идеале, хостер - юр лицо, с сертификатами на телематику, своим сданным узлом связи, с разрешением на эксплуатацию в Роскомнадзоре (1)
Для начала, что надо.
Нужна ли лицензия хостеру? (2)
Сдача узла связи для хостинговых компаний
На своё оборудование ССС обязателен. Сертификаты соответствия - оборудование должно быть сертифицировано для оказания услуг связи.
Получать ли лицензию на телематику - вопрос очень спорный, и по ссылкам (например (2)) ясности не добавится. Так что телематику лучше получить:
Без лицензии -- статья 171 уголовного кодекса; с лицензией без сданного узла связи - штраф до 20 тыс. руб. в соответствии с КоАП.
http://forum.hostobzor.ru/lofiversion/index.php/t8585.html
Вот узел связи во многих случаях получается можно и не сдавать, пока обороты не превысят 5-10 млн в год - закрыть-то можно легко, а вот денег состричь уже не сильно выйдет. А если будет именно указание закрыть - и наличие всех документов не поможет. Хотя при хороших оборотах лучше всё-таки озаботиться всеми лицензиями.
четверг, 12 июля 2012 г.
Новые процессоры intel: square и narrow сокеты
"Следующим новшеством платформ, стало применение двух типов установочных сокетов под процессоры ILM (Independent Loading Mechanism). Называются они Square ILM и Narrow ILM. Отличаются они размерами крепежных отверстий: в Square ILM 80×80, а Narrow ILM 94×56. Под каждый тип крепления, будут необходимы свои типы радиаторы или соответственно кулера, линейка которых значительно расширилась. Теперь при выборе устройств охлаждения, под 26xx серию процессоров, надо быть внимательней, т.к. ОНИ НЕ ВЗАИМОЗАМЕНЯЕМЫ, т.е. радиатор или кулер под Square ILM 80×80 не подойдет на сокеты Narrow ILM 94×56 и наоборот.
Если Square ILM признается компанией Intel как штатный разъем (в документации назван Regular), то Narrow ILM предназначен для высокоплотных систем, дающий возможность размещения большего количества слотов памяти и изменения охлаждающих потоков."
http://blog.servergid.ru/?p=286
И небольшая напоминалка: для 1-процессорных систем на лето 2012 актуален сокет 1155, для 2+ сокетных - 2011 с учётом того что выше. Остальные имеют смысл только для обновления или расширения парка с таким железом.
Если Square ILM признается компанией Intel как штатный разъем (в документации назван Regular), то Narrow ILM предназначен для высокоплотных систем, дающий возможность размещения большего количества слотов памяти и изменения охлаждающих потоков."
http://blog.servergid.ru/?p=286
И небольшая напоминалка: для 1-процессорных систем на лето 2012 актуален сокет 1155, для 2+ сокетных - 2011 с учётом того что выше. Остальные имеют смысл только для обновления или расширения парка с таким железом.
вторник, 10 июля 2012 г.
Обходим блокировку википедии
Если попытаться получить доступ "как обычно", получим уй. Впрочем, у них не заблокирована мобильная версия, которая доступна так: берётся нужный урл и между ru.wikipedia вписываем mobile, получив ru.mobile.wikipedia.org/...
понедельник, 9 июля 2012 г.
ssh: отключаем проверки отпечатка
Бывает нужно отключить проверку отпечатков, например внутри локалки, и особенно актуально для автоматических скриптов.
Вариант 1: ssh -o StrictHostKeyChecking=no host.ru
Оно же, без записи ключа в known_hosts: ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null host.ru
Вариант 2: в ~/.ssh/config:
Вариант 1: ssh -o StrictHostKeyChecking=no host.ru
Оно же, без записи ключа в known_hosts: ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null host.ru
Вариант 2: в ~/.ssh/config:
Host 192.168.0.* StrictHostKeyChecking no UserKnownHostsFile=/dev/null
воскресенье, 8 июля 2012 г.
11 «рецептов приготовления» MySQL в Битрикс24
11 «рецептов приготовления» MySQL в Битрикс24
Хотя мы на своих проектах битрикс используем только там, где важнее скорость разработки, фреймворк конечно не идеален, подводных камней море, но ничего сильно лучше даже из платных пока не встречали.
А вот проекты, где ожидаются большие нагрузки, уже переписываем на других цмс, в том числе на нашей собственной. Причин много. В частности, bitrix corportal тормозит на честном 8-ядернике, саппорт помогать отказывается (действующая лицензия разработчика. При запросах помощи - общие слова, отсылки на форум, и фразы вроде "у вас не работает LocalRedirect и пока не поправите, помочь ничем не можем". При том, что это их баг, который точно не виноват - сайт на https висит, но дальше на nginx общение с апачем по http. Итд.).
Причина в их технологии "инфоблоки". Все ускорения вроде APC, memcached, nginx, тюнинга БД были выполнены. А в нормальной цмс копаться в самом движке - идея крайне плохая.
Хотя мы на своих проектах битрикс используем только там, где важнее скорость разработки, фреймворк конечно не идеален, подводных камней море, но ничего сильно лучше даже из платных пока не встречали.
А вот проекты, где ожидаются большие нагрузки, уже переписываем на других цмс, в том числе на нашей собственной. Причин много. В частности, bitrix corportal тормозит на честном 8-ядернике, саппорт помогать отказывается (действующая лицензия разработчика. При запросах помощи - общие слова, отсылки на форум, и фразы вроде "у вас не работает LocalRedirect и пока не поправите, помочь ничем не можем". При том, что это их баг, который точно не виноват - сайт на https висит, но дальше на nginx общение с апачем по http. Итд.).
Причина в их технологии "инфоблоки". Все ускорения вроде APC, memcached, nginx, тюнинга БД были выполнены. А в нормальной цмс копаться в самом движке - идея крайне плохая.
среда, 4 июля 2012 г.
свичи raisecom
Прикупили модель iscom2128, которая интересна тем, что у нее 24 сотки и 4(!) гигабит комбо порта (медь+SFP)
При этом это наиболее странная железка, с какой приходилось работать из таких свичей. Синтаксис собственный, во многом нелогичный (например, обычно айпи вешают не на порт, а на vlan, а тут непойми на что). Работа в вланами совершенно непонятна, развешивание режимов работы портов, всяких tagged-untagged и прочего на цисках/эджкорах осваивается за пол часа, тут за 2 дня настроить не удалось и было отложено на год+. Благо, пока неактуально... итд.
Итак, что читать
общее описание (введение)
по свичу
При этом это наиболее странная железка, с какой приходилось работать из таких свичей. Синтаксис собственный, во многом нелогичный (например, обычно айпи вешают не на порт, а на vlan, а тут непойми на что). Работа в вланами совершенно непонятна, развешивание режимов работы портов, всяких tagged-untagged и прочего на цисках/эджкорах осваивается за пол часа, тут за 2 дня настроить не удалось и было отложено на год+. Благо, пока неактуально... итд.
Итак, что читать
общее описание (введение)
по свичу
Некоторые ошибки mysql 5.5
1 В оригинальном 5.5 и модификациях типа перконы убрана из блока mysqld опция default-character-set, в результате в логе может быть ошибка
mysqld: unknown variable 'default-character-set=cp1251'
В секции [client] она рабочая.
Решение: убрать эту опцию из [mysqld] и добавить
init-connect='SET NAMES cp1251'
также возможно
skip-character-set-client-handshake
Если нужна именно такая строка - оставайтесь на 5.1/5.0
2 Странная ошибка в debian
ERROR 1133 (42000): Can't find any matching row in the user table
при попытке выполнить
grant all privileges on test.* to user@localhost identified by 'pass';
Причина первая: если такого юзера нет, и прописываем identified by '' - надо сначала создать юзера. Багу много лет, но никому нет дела. Но вообще юзеры без пароля - плохая практика.
Если что - создать юзера: CREATE USER 'user'@'localhost' IDENTIFIED BY 'some_pass';
Но если и на create user выдаст
ERROR 1396 (HY000): Operation CREATE USER failed for 'user'@'localhost'
то всё грустно. См причину 2, и ошибку 3.
Причина вторая: надо сделать flush privileges и после этого команда отработает как надо. Но один раз вызвало ошибку номер 3 (см ниже)
3 Ошибка в debian, с которой за неделю довелось столкнуться десяток раз:
error: 'Access denied for user 'debian-sys-maint'@'localhost' (using password: YES)'
Часто каким-то образом следовало из ошибки 2. Это спец юзер для обслуживания сервера, характерен только для debian.
Сначала делаем
cat /etc/mysql/debian.cnf
и копируем оттуда пароль. теперь коннектимся от рута к базе (если он неизвестен - есть опция --skip-grant-tables) и выполняем запрос
GRANT RELOAD, SHUTDOWN, PROCESS, SHOW DATABASES, SUPER, LOCK TABLES ON *.* TO 'debian-sys-maint'@'localhost' IDENTIFIED BY 'пароль-из-файла-выше';
flush privileges;
Некоторые указывают GRANT ALL PRIVILEGES... WITH GRANT OPTION; но я не знаю, есть ли в этом нужда и не опасно ли это.
4 особенности с includedir
Багу также много лет. Игнорируются файлы, в названии которых больше одной точки, плюс расширение обязано быть .cnf, что означает полную недопустимость точек в имени до расширения.
Например, general.cnf будет учтён, а вот general.mynode.cnf будет просто проигнорирован. Судя по тому, что на ошибки в таких файлах не ругается, их даже не открывает.
mysqld: unknown variable 'default-character-set=cp1251'
В секции [client] она рабочая.
Решение: убрать эту опцию из [mysqld] и добавить
init-connect='SET NAMES cp1251'
также возможно
skip-character-set-client-handshake
Если нужна именно такая строка - оставайтесь на 5.1/5.0
2 Странная ошибка в debian
ERROR 1133 (42000): Can't find any matching row in the user table
при попытке выполнить
grant all privileges on test.* to user@localhost identified by 'pass';
Причина первая: если такого юзера нет, и прописываем identified by '' - надо сначала создать юзера. Багу много лет, но никому нет дела. Но вообще юзеры без пароля - плохая практика.
Если что - создать юзера: CREATE USER 'user'@'localhost' IDENTIFIED BY 'some_pass';
Но если и на create user выдаст
ERROR 1396 (HY000): Operation CREATE USER failed for 'user'@'localhost'
то всё грустно. См причину 2, и ошибку 3.
Причина вторая: надо сделать flush privileges и после этого команда отработает как надо. Но один раз вызвало ошибку номер 3 (см ниже)
3 Ошибка в debian, с которой за неделю довелось столкнуться десяток раз:
error: 'Access denied for user 'debian-sys-maint'@'localhost' (using password: YES)'
Часто каким-то образом следовало из ошибки 2. Это спец юзер для обслуживания сервера, характерен только для debian.
Сначала делаем
cat /etc/mysql/debian.cnf
и копируем оттуда пароль. теперь коннектимся от рута к базе (если он неизвестен - есть опция --skip-grant-tables) и выполняем запрос
GRANT RELOAD, SHUTDOWN, PROCESS, SHOW DATABASES, SUPER, LOCK TABLES ON *.* TO 'debian-sys-maint'@'localhost' IDENTIFIED BY 'пароль-из-файла-выше';
flush privileges;
Некоторые указывают GRANT ALL PRIVILEGES... WITH GRANT OPTION; но я не знаю, есть ли в этом нужда и не опасно ли это.
4 особенности с includedir
Багу также много лет. Игнорируются файлы, в названии которых больше одной точки, плюс расширение обязано быть .cnf, что означает полную недопустимость точек в имени до расширения.
Например, general.cnf будет учтён, а вот general.mynode.cnf будет просто проигнорирован. Судя по тому, что на ошибки в таких файлах не ругается, их даже не открывает.
вторник, 3 июля 2012 г.
Разные robots.txt
Зачастую бывает так, что несколько сайтов указывают в 1 каталог. Чаще всего это характерно для поддоменов. И бывает нужно отдавать на разные домены разные robots.txt.
Решения задачи:
0) передавать на обработку этого файла апачу, который уже скриптом будет отдавать нужный текст.
1) под каждый поддомен создать свой server c разными root
2) rewrite + map
3) через try_files
Решения задачи:
0) передавать на обработку этого файла апачу, который уже скриптом будет отдавать нужный текст.
1) под каждый поддомен создать свой server c разными root
2) rewrite + map
map $host $robots {
default robots.txt;
one.domain.com one.domain.robots.txt;
...
}
server {
location = /robots.txt {
alias /path/to/$robots;
}
...
}
(линк), "для любителей граблей"3) через try_files
location = /robots.txt {
try_files /$host.robots.txt /robots.txt =404;
}
Для работы должен быть определён root. Можно и в блоке robots, если например эти файлы вынесены в отдельное место.
понедельник, 2 июля 2012 г.
nginx: regex в server_name
Штатно есть весьма удобный функционал с регэкспами в server_name (далее блок), позволяющий весьма интересные трюки. (дока) Но проблема в том, что использование таких регэкспов таит много подводных камней.
Например, если мы определили .site.ru, регулярки на отдельный блок, даже если оно помещено выше главного блока, работать не будут. Вот такой прикол.
Причина в том, что у регулярок приоритет минимален и выбираются они, когда остался только блок по умолчанию (что неявно и описано в доке выше).
Для примера возьмём задачу редиректа с доменов вида www.sub.site.ru на sub.site.ru (где поддоменов sub может быть десятки и сотни). Правильнее всего вынести домены, с которых нужен редирект, в отдельный блок. Но вроде простая задача "в лоб" не решается, см. описание выше. Поэтому придуманы варианты (в порядке возрастания извращений, но не быстродействия):
0) передать заботу редиректов фронтенду. Тому же апачу.
1) в главный блок пихать
if ($host ~* ^www\.(w+\.site\.ru)$) {
set $newdomain $1;
rewrite ^(.*)$ http://$newdomain$1 permanent;
}
Но... IfIsEvil
2) улучшенный 1). Подключить встроенный перл и им обрабатывать $host
3) для каждого поддомена www.(sub).site.ru сделать отдельный блок и там return 301 sub.site.ru. Идеальный вариант, если поддоменов 1-10 и-или их количество расти не будет. Задача частично может решиться скриптами автогенерации блоков. Для нагруженных серверов пожалуй оптимальный вариант.
4) Пропихнуть в nginx патчи для поднятия приоритета регэкспам.
Но есть вариант проще, тоже вполне рабочий.
!!! В таком описании указывать *.site.ru или .site.ru недопустимо! Отвалится первый блок.
Для облегчения работы можно в первом блоке сделать именованную переменную (иначе при первом же регэкспе во всяких там location потеряем значение), тогда будет так:
server_name ~^www\.(?<domain>.+\.site\.ru)$;
и работаем с $domain
или потом в коде установить переменную
set $newdomain $1;
Например, если мы определили .site.ru, регулярки на отдельный блок, даже если оно помещено выше главного блока, работать не будут. Вот такой прикол.
Причина в том, что у регулярок приоритет минимален и выбираются они, когда остался только блок по умолчанию (что неявно и описано в доке выше).
Для примера возьмём задачу редиректа с доменов вида www.sub.site.ru на sub.site.ru (где поддоменов sub может быть десятки и сотни). Правильнее всего вынести домены, с которых нужен редирект, в отдельный блок. Но вроде простая задача "в лоб" не решается, см. описание выше. Поэтому придуманы варианты (в порядке возрастания извращений, но не быстродействия):
0) передать заботу редиректов фронтенду. Тому же апачу.
1) в главный блок пихать
if ($host ~* ^www\.(w+\.site\.ru)$) {
set $newdomain $1;
rewrite ^(.*)$ http://$newdomain$1 permanent;
}
Но... IfIsEvil
2) улучшенный 1). Подключить встроенный перл и им обрабатывать $host
3) для каждого поддомена www.(sub).site.ru сделать отдельный блок и там return 301 sub.site.ru. Идеальный вариант, если поддоменов 1-10 и-или их количество расти не будет. Задача частично может решиться скриптами автогенерации блоков. Для нагруженных серверов пожалуй оптимальный вариант.
4) Пропихнуть в nginx патчи для поднятия приоритета регэкспам.
Но есть вариант проще, тоже вполне рабочий.
server {
server_name ~^www\.(\w+\.site\.ru)$;
return 301 http://$1$request_uri;
}
server {
server_name site.ru www.site.ru ~^\w+\.site\.ru$;
....
}
!!! В таком описании указывать *.site.ru или .site.ru недопустимо! Отвалится первый блок.
Для облегчения работы можно в первом блоке сделать именованную переменную (иначе при первом же регэкспе во всяких там location потеряем значение), тогда будет так:
server_name ~^www\.(?<domain>.+\.site\.ru)$;
и работаем с $domain
или потом в коде установить переменную
set $newdomain $1;
Подписаться на:
Сообщения (Atom)