- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Маркетинг для шоколадной фабрики. На 34% выше средний чек
Через устранение узких мест
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Имеется веб-сервер с убунту 11.10 apache2 и php5.3. На сервере имеются доп. Ip в виде виртуальных интерфейсов.
/etc/network/interfaces выглядит так:
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address X.X.220.18
netmask 255.255.255.248
gateway X.X.220.17
auto eth0:1
iface eth0:1 inet static
address X.X.220.19
netmask 255.255.255.248
#gateway X.X.220.17
auto eth0:2
iface eth0:2 inet static
address X.X.220.20
netmask 255.255.255.248
#gateway X.X.220.17
auto eth0:3
iface eth0:3 inet static
address X.X.232.42
netmask 255.255.255.248
#gateway X.X.220.17
auto eth0:4
iface eth0:4 inet static
address X.X.232.43
netmask 255.255.255.248
#gateway X.X.220.17
auto eth0:5
iface eth0:5 inet static
address X.X.232.44
netmask 255.255.255.248
#gateway X.X.220.17
auto eth0:6
iface eth0:6 inet static
address X.X.232.45
netmask 255.255.255.248
#gateway X.X.220.17
auto eth0:7
iface eth0:7 inet static
address X.X.232.46
netmask 255.255.255.248
#gateway X.X.220.17
Некоторый скрипт выполняет запросы используя curl. Скрипт каждый раз меняет ip с которого выполняет запрос. Делается это с помощью curl_setopt($c,CURLOPT_INTERFACE,<ip адрес интерфейса>). До вчерашнего дня все работало отлично. Никаких работ на сервере не проводилось, ось не обновлялась.
На данный момент при каждом запросе curl_error выдает такое сообщение: "Couldn't bind to '<ip адрес интерфейса>'". И запрос, очевидно, завершается неудачно.
В чем может быть дело? Заранее спасибо!
IP пропал например
На данный момент при каждом запросе curl_error выдает такое сообщение: "Couldn't bind to '<ip адрес интерфейса>'". И запрос, очевидно, завершается неудачно.
В чем может быть дело?
Как вам намекнули - стоит обратить внимание на актуальное состояние активных интерфейсов. Команда: ip (ip addr, ip route, etc). Сравните с содержимым /etc/network/interfaces.
Второй момент: отваливается *всегда*? Даже когда скрипт биндится на основной IP сервера? Если все-таки не всегда - может просто сокеты кончаются? Если это VPS - тем более вероятно напороться на какой-то лимит.
Если не хотите продолжать гадать - наймите системного администратора.
Блин, ребята помогите разобраться. Третий день уже маюсь.
Вот что я сделал:
Версия что пропали IP:
Повесил виртуальный хост апача на один из ip. Результат: все работает прекрасно. Значит с ip все норм.
Версия что php по каким то причинам не может использовать интерфейсы:
убираю полностью опцию CURLOPT_INTERFACE, т.е. тогда запрос должен пойти через основной интерфейс. Так и есть, запрос идет через основной интерфейс, при чем идет нормально. Но вот загадка, назначаю CURLOPT_INTERFACE ip Того же самого основного интерфейса и опять выходит ошибка 'Couldn't bind to <ip>'
Полностью переустановил ОСь. Проблема не ушла.
Что за магия?
---------- Добавлено 26.06.2012 в 12:17 ----------
Проблемы решил сам. Все оказалось как обычно проще простого.
Дело вот в чем: сайт, к которому обращался посредством cURL мой скрипт, добавил в свои dns записи IPv6 адрес. Далее, cURL, разрешив ip относительно домена, почему то приоритетным выбирал v6 адрес, и, очевидно, на локальном интерфейсе искал ipv6 адрес для соединения с удаленным v6 адресом.
Проблема решилась установкой следующей опции CURL: CURLOPT_IPRESOLVE=CURL_IPRESOLVE_V4.
Всем спасибо за внимание, тему можно закрывать.