Как мне настроить apache, чтобы такие домены, как example.com и www.example.com, обслуживали один и тот же контент?
У меня есть домен - example.com .
Ниже приведены мои записи DNS .
example.com A IP address
www.example.com A IP address
Вот моя конфигурация виртуального хоста Apache .
<VirtualHost *:80>
ServerName www.example.com
DocumentRoot /var/www/public_html/www.example.com
</VirtualHost>
Теперь, когда я набираю example.com (без www часть) в моем браузере я получаю страницу по умолчанию Apache , а не файл из DocumentRoot . Когда я добавляю www в свой домен, все в порядке.
Теперь возникает вопрос , как это настроить, чтобы оба домена www.example.com и example.com обслуживали один и тот же файл из корня документа? Должен ли я обрабатывать это на уровне DNS или как-то настроить веб-сервер? Я новичок во всем этом, так что вопрос, наверное, глупый.root @ server2 'cd /root/.example; git pull origin master '...
Я пытаюсь установить ssh с сервера 1 на сервер 2 и выполнить git pull с сервера 1 на сервер 2.
Итак, на сервере 1 я выполните следующую команду:
ssh root@server2 'cd /root/.example; git pull origin master'
, но это дает мне эту ошибку:
Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
Он может использовать ssh, потому что, когда я выполняю ls ( ssh root @ server2'cd /root/.example; ls ) Я вижу содержимое каталога /root/.example . Он просто не может выполнить git pull origin master , потому что он использует неправильный ключ.
Что я могу сделать по-другому?
Я использую Centos 6.
Вам нужно ssh для пользователя, имеющего доступ к git-репозиторию. Если вы ssh-интервьюируете с root'ом, убедитесь, что у root'а есть хотя бы права на репо (в случае, если вы используете какую-то умную версию git'а, например gitolite, gitlab и т.д.).
BTW, если вы пытаетесь сделать релиз с этим, используйте git fetch && git reset --hard origin/master вместо git pulch. Git pull производит слияние и может заканчиваться конфликтами, git reset просто перемещает реальный указатель головы на другой коммит без слияния.
Переадресация агента SSH
по умолчанию ssh не выполняет переадресацию агента. Таким образом, хотя на вашем клиенте вы загрузили свой ключ ssh с помощью ssh-agent, этот же ключ недоступен для «повторного использования» на удаленной машине в сеансе ssh.
Вы можете вручную сделать его доступным в месте назначения с помощью -A, но сначала прочитайте предупреждения безопасности на странице руководства (ниже)
Следующее использует переадресацию агента, может ssh на github на удаленном компьютере. Если удаленный хост находится под контролем злоумышленника, он может использовать ваш ssh-агент, чтобы «действовать от вашего имени» с другими системами:
ssh -A root@server2
man ssh:
-Aагент, такой как ssh-agent(1). Это также можно указать на для каждого хоста в файле конфигурации.Переадресацию агента следует включать с осторожностью.Пользователи с возможностью обхода прав доступа к файлам на удаленке хост (для сокета UNIX-домена агента) может получить доступ к локального агента через перенаправленное соединение. Злоумышленник не могут получить ключевой материал от агента, однако они могут выполнять операции над ключами, которые позволяют им аутентифицироваться с использованием удостоверений, загруженных в агент. А более безопасной альтернативой может быть использование узла перехода (см.
-J).