Сообщение в блоге "Служба tinyurl для вашего домена"объясняет, как настроить службу ShortName для вашего домена с помощью Google Apps. Например, если ваш домен example.com и вы используете Google Apps, вы можете настроить его так, чтобы http://go.example.com - это личная служба ShortName вашего предприятия.
ПРИМЕЧАНИЕ. Речь идет не о создании службы "tinyurl" для использования во всем мире. Это для предприятия.
Полезно иметь службу коротких имен, которую могут использовать только ваши пользователи, чтобы вы могли создавать ссылки на внутренние страницы. Вместо того, чтобы сообщать людям длинный сложный URL, вы можете сказать: «Сегодняшнее обеденное меню http://go.example.com/lunch". Сообщение в блоге документирует некоторые преимущества предоставления людям возможности создавать свои собственные ссылки. (Самое главное: им не нужно беспокоить ВАС, чтобы создать новую ссылку!)
Проблема с системой в том, что URL-адрес все еще довольно длинный. Люди предпочитают набирать в браузере команду «пойти / пообедать» и заставить ее работать. К сожалению, Google Apps не может поддерживать это из-за технических особенностей работы протокола HTTP. В заголовке «Host:» в HTTP 1.1 указан домен, который пользователь ввел в свой веб-браузер, а не FQDN. Другими словами, когда Google Apps получает HTTP-запрос для "http: // go / обед"веб-сервер получает" go "в качестве имени хоста. Поскольку Google Apps предоставляет эту услугу для многих доменов, он не может определить, хотите ли вы go.example.com или go.some-other-example.com.
В результате пользователям приходится каждый раз вводить «go.example.com/lunch», что намного дольше, чем «идти / ланч».
Google может решить эту проблему, используя веб-файлы cookie или другую схему. Ни один из них не является особенно чистым или легким. Пока они этого не сделают, вы можете решить проблему, настроив свою собственную машину, которая принимает запросы как «готовые» и перенаправляет их.
Сервер принимает HTTP-запросы для сайта с именем "go" и перенаправляет запрос на go.example.com. Затем вы создаете правильные записи DNS, чтобы они работали, и изменяете настройки DHCP, чтобы ваши ноутбуки / рабочие станции работали правильно.
Смысл этого документа о сбое сервера - объяснить процесс, а затем привести примеры конфигурации, которые помогут вам сделать это для вашего сайта. Поскольку у меня нет доступа или знаний о каждой операционной системе в мире, я делаю это «вики сообщества», чтобы люди могли заполнять фрагменты конфигурации, когда они заставят ее работать на них. Я поместил «TODO» в области, которые особенно нуждаются в улучшении.
В этом примере мы будем использовать example.com в качестве домена.
Настроить сервис для go.example.com как обычно. Проверьте это и убедитесь, что URL-адрес вроде http://go.example.com/foo работает. Не продолжайте, если это не завершено. Это все равно что пытаться отремонтировать свою машину, прежде чем она у вас появится.
Если ваш сервис коротких имен go.example.com, в идеале вы должны сделать имя своего перенаправителя go.example.com. К сожалению, физика не позволяет двум телам находиться в одном месте в одно и то же время, а DNS подчиняется законам физики.
Хитрость заключается в том, чтобы перенаправитель имел то же имя хоста, что и служба ShortName, но в другом домене. Например, go.corp.example.com, go.ext.google.com, или go.this-is-different.example.com.
У крупных компаний обычно есть внутренний субдомен, который не открыт для внешнего мира. Обычно внутренние хосты INSIDEHOST.corp.google.com. Вот куда вы помещаете перенаправитель.
Некоторые компании выделяют поддомен, полный CNAME, указывающих на службы, к которым следует обращаться как внутри компании, так и за ее пределами. Таким образом, есть один поддомен, который нужно поместить в путь поиска DNS людей. (Пользователи Unix могут думать об этом как о том, что /usr/local/bin быть подкаталогом, полным символических ссылок) Традиционно этот поддомен ext.example.com. В этом поддомене есть CNAME, например mail.ext.example.com, calendar.ext.example.com, vpn.ext.example.com, и так далее.)
Предупреждение. Добавление еще одного элемента в ваш путь поиска DNS - еще один способ замедлить работу ваших компьютеров. Выполнение дополнительного DNS-запроса КАЖДЫЙ раз выполняется медленно, и просмотр веб-страниц будет заметно медленнее. Гораздо лучше добавить этот перенаправитель в поддомен, который уже находится в пути поиска DNS вашего компьютера, даже если это означает добавление CNAME в несколько поддоменов. Например, если ваши внутренние машины и машины, подключенные к вашей VPN, имеют corp.example.com в их пути поиска, добавьте туда CNAME. Если вы хотите, чтобы внешние машины, не подключенные к VPN, имели доступ к перенаправителю, это может быть странно для жесткого кода corp.example.com в их путь поиска, если это поддомен для машин, к которым не было доступа извне. В этом случае другой CNAME может быть добавлен во внешний субдомен (например, ext.example.com), чтобы указать на перенаправитель. Обновите конфигурацию веб-сервера для поддержки обоих.
В этом примере предположим, что вы выбрали перенаправитель go.ext.example.com. Машину можно назвать как угодно, мы сделаем все волшебство в DNS и настройке веб-сервера.
Веб-сервер, который вы собираетесь настроить, может быть на существующем веб-сервере или на новом, созданном специально для этой цели. Суть в том, что машина должна быть доступна из любого места, где вы хотите, чтобы служба ShortName работала: внутри компании, за пределами компании, когда пользователь подключен через VPN. (Вы можете отказаться от этой работы извне по соображениям безопасности. Вы также можете из соображений безопасности установить одну машину внутри, а другую снаружи.)
Примечание. Для этого не нужно настраивать новый веб-сервер. Вы можете добавить это к уже существующему веб-серверу, если конфигурация не существует.
Примечание: это может быть довольно сложно. Возможно, вы захотите сосредоточиться на том, чтобы это работало в самом простом случае, а затем, когда оно будет работать и протестировано, заставить его работать в других ситуациях. В частности, заставьте его работать в следующем порядке: 1. рабочие станции / ноутбуки внутри компании 2. ТО машины, подключенные через VPN, затем машины за пределами компании (например, в Интернет-кафе). 3. ТО машины вне сети, без VPN 4. ЗАТЕМ проверьте это для других операционных систем.
В этом примере мы предполагаем, что существует веб-сервер, доступный по одному и тому же IP-адресу, независимо от того, находитесь ли вы внутри компании или за ее пределами.
В нашем "go.корп.example.com ", это означает, что" перейти "находится в субдомене, который доступен только для инсайдеров, и требует, чтобы VPN использовала службу ShortName. Поскольку Google Apps обычно настроены для работы без VPN (поскольку весь доступ предоставляется HTTPS), это неоптимально.
В нашем "go.доб.example.com ", это означает, что субдомен доступен как внутри компании, так и за ее пределами, а A запись указывает на внешний IP-адрес.
Вот необходимые записи DNS:
go.example.com. IN CNAME ghs.google.com.
go.ext.example.com. IN A 64.32.179.5
go-redirector.example.com IN A 64.32.179.5
Первая запись DNS (go.example.com) должна существовать уже на этапе 1.
Вторая запись DNS (go.доб.example.com) - это A запись, указывающая на IP-адрес нового веб-сервера, который вы настраиваете.
Третья запись DNS (go-redirector) поможет вам при отладке.
Добавьте перенаправление на веб-сервер. (Предполагается, что веб-сервер уже установлен и запущен).
Вот фрагмент конфигурации Apache:
<VirtualHost *:80>
ServerName go-redirector.example.com
ServerAlias go, go.ext, go.ext.example
RewriteEngine on
RewriteRule ^(.*)$ http://go.example.com$1 [R=permanent]
</VirtualHost>
Как это проверить. http://go-redirector.example.com должен работать на этом этапе.
Не продолжайте, пока этот тест не сработает. Шаги малыша.
Теперь мы собираемся настроить машины (все, что запускает веб-браузер) так, чтобы путь поиска DNS включал "ext.example.com"
На вашем DHCP-сервере и VPN-сервере отправьте путь поиска DNS, который:
corp.example.com.
(поддомен с хостом перенаправления, за которым следует ".")
В качестве альтернативы вы можете использовать путь поиска, например:
corp.example.com example.com.
Однако это добавит дополнительный DNS-поиск для КАЖДОЙ чертовой веб-страницы, на которую мы переходим. Так как они будут терпеть неудачу в 99% случаев, это только замедлит веб-серфинг.
На рабочих станциях и ноутбуках вам необходимо убедиться, что субдомен включен в их путь поиска DNS. Таким образом, когда пользователь наберет «идти», программа найдет его в домене.
Мы хотим настроить путь поиска на машине так, чтобы он включал этот поддомен всеми возможными способами:
Первоначально путь поиска DNS не мог быть установлен через DHCP. Это недавно добавленная функция, и не все клиенты DHCP ее поддерживают. Даже DHCP-клиенты, которые его поддерживают, должны быть изменены, потому что, когда ноутбук находится (например) в Интернет-кафе, он обращается к серверу DHCP, который вы не контролируете. Когда ноутбук использует VPN, программное обеспечение VPN-клиента на самом деле не использует DHCP, но обычно есть способ, которым VPN-сервер передает настройки, которые обычно получаются от DHCP-сервера.
Поэтому вы хотите установить путь поиска DNS во всех этих местах:
corp.example.com домен в свой путь поиска, если DHCP-сервер еще не включил его.Ниже приведены инструкции о том, как это сделать на различных DHCP-серверах и операционных системах.
ДЕЛАТЬ
Если путь поиска - это просто домен, в котором должна находиться машина, тогда:
option domain-name "corp.example.com";
Если клиенты поддерживают RFC 3397 для предоставления пути поиска, вы можете сделать это, но это неудобно, поскольку нет встроенной поддержки для типа данных, который представляет собой последовательность хостов DNS, каждый из которых закодирован как метки с префиксом длины, как в DNS. Невозможно записать значения параметра, определенного как массив записей, где запись содержит массив другой записи, поэтому вы можете использовать строку данных для кодирования вещей вручную.
option dns-search-domains code 119 = string;
option dns-search-domains concat(
encode-int(4,1), "corp", encode-int(7,1), "example", encode-int(3,1), "com", encode-int(0,1),
encode-int(7,1), "example", encode-int(3,1), "com", encode-int(0,1)
);
который должен (непроверенный) создать список поиска из двух элементов.
ДЕЛАТЬ
ДЕЛАТЬ
редактировать /etc/resolv.conf и убедитесь, что (1) "domain corp.example.com" - это первая строка, (2) добавьте / отредактируйте строку "search", чтобы включить corp.example.com domain, (3) добавьте строку «options ndotes: 2», чтобы снизить нагрузку на ваши DNS-серверы.
domain corp.example.com
search corp.example.com exmaple.com
options ndots:2
TODO заполнить для Windows, Linux и т. Д.
Теперь пользователи должны иметь возможность указать:
http: // go / foo http: //go.example/foo http://go.example.com/foo
Фактически, в качестве проверки достоверности вы захотите проверить эти URL-адреса во всех ситуациях:
( each OS you support ) * ( internal LAN / at an Internet cafe / while on the VPN )
И, наконец, один совет: даже если вы проделали это безупречно, вы все равно рискуете http://go/foo ссылка не работает, когда человек пытается ввести ее на компьютере, который вы не настроили, чтобы путь поиска DNS включал ваш домен. Поэтому вам следует публиковать ссылки, используя полный URL: http://go.example.com/foo; и найдите время, чтобы обучить отдел по связям с общественностью вашей компании и других, чтобы они всегда указывали это именно так.
Или, по крайней мере, закодируйте их в HTML, чтобы в тексте ссылки было видно «go», но фактический HREF переходит в полное доменное имя:
<a href="http://go.example.com/lunch">go/lunch</a>
Обучить этому людей в PR-отделе может быть сложно. Вы можете просто сказать им, что они должны использовать длинную версию (go.example.com) во всем пишут, потому что короткое «иди / обед» срабатывает только случайно.
TODO: подумайте, как поступить с HTTPS (сертификацию будет очень сложно, если вообще возможно, получить правильно).
Этот вопрос следует так или иначе пометить как «отвеченный». Таким образом, https://serverfault.com/unansaged URL останется верным. Пожалуйста (отправьте и) примите «ответ» на этот вопрос. Спасибо!
Моим «ответом» было бы то, что создание (или установка) службы сокращения ссылок чрезвычайно просто, и вместо того, чтобы прыгать через все описанные выше проблемы, просто настройте локальный сокращатель ссылок на веб-сервере, который отвечает на «идти». example.com "и убедитесь, что ваш DNS отвечает на поиск example.com. Таким образом, внутренние URL-адреса не попадут в мир. (Возможно, я упускаю суть.)
Альтернативы:
В очень маленькой компании или рабочей группе попросите у всех их любимые закладки и найдите место, чтобы разместить их на первой странице интрасети.
В качестве альтернативы можно развернуть интрасеть для своей небольшой компании или группы в виде вики-страницы с удобным списком общих горячих ссылок, которые помогут людям попасть туда, куда они, вероятно, захотят пойти.
Ура, -дэнни