Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Advertencia al iniciar / reiniciar Apache "Failed to resolve server name..."
57 views
Skip to first unread message
Mauro Antivero
Nov 6, 2014, 11:30:03 AM11/6/14
to
Estimados, tengo un servidor con Debian Wheezy 7.7 con una IP privada
(172.30.7.122/24) corriendo Apache para hacer unas pruebas con OwnCloud.
He configurado todo para tener acceso solamente por HTTPS y si bien
parece funcionar correctamente (tengo acceso por HTTPS a la página de
OwnCloud), cuando reinicio Apache me encuentro con la siguiente
advertencia la cual me molesta mucho:
service apache2 restart
[....] Restarting web server: apache2[Thu Nov 06 13:11:31 2014] [error]
(EAI 2)Name or service not known: Failed to resolve server name for
172.30.7.122 (check DNS) -- or specify an explicit ServerName
... waiting [Thu Nov 06 13:11:32 2014] [error] (EAI 2)Name or service
not known: Failed to resolve server name for 172.30.7.122 (check DNS) --
or specify an explicit ServerName
Buscando en Internet salen numerosas entradas que hacen referencia a
este tema, pero en todas ellas básicamente dice que se resuelve
agregando la línea:
ServerName
Al archivo "/etc/apache2/apache2.conf"
Pues lo he hecho y me sigue pasando exactamente lo mismo...
Por cierto, este es el contenido del archivo
"/etc/apache2/conf.d/owncloud.conf"
<VirtualHost 172.30.7.122:443>
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/owncloud.pem
SSLCertificateKeyFile /etc/apache2/ssl/owncloud.key
DocumentRoot /var/www/owncloud/
ServerName nombre_servidor.dominio
<Directory /var/www/owncloud>
AllowOverride All
order allow,deny
Allow from all
</Directory>
</VirtualHost>
Nota: Por supuesto que en ambos archivos "nombre_servidor.dominio" es
reemplazado por el nombre y dominio que corresponde.
Les agradecería mucho si me pueden dar una mano con este tema.
Saludos, Mauro.
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/545B9FA8...@gmail.com
(172.30.7.122/24) corriendo Apache para hacer unas pruebas con OwnCloud.
He configurado todo para tener acceso solamente por HTTPS y si bien
parece funcionar correctamente (tengo acceso por HTTPS a la página de
OwnCloud), cuando reinicio Apache me encuentro con la siguiente
advertencia la cual me molesta mucho:
service apache2 restart
[....] Restarting web server: apache2[Thu Nov 06 13:11:31 2014] [error]
(EAI 2)Name or service not known: Failed to resolve server name for
172.30.7.122 (check DNS) -- or specify an explicit ServerName
... waiting [Thu Nov 06 13:11:32 2014] [error] (EAI 2)Name or service
not known: Failed to resolve server name for 172.30.7.122 (check DNS) --
or specify an explicit ServerName
Buscando en Internet salen numerosas entradas que hacen referencia a
este tema, pero en todas ellas básicamente dice que se resuelve
agregando la línea:
ServerName
Al archivo "/etc/apache2/apache2.conf"
Pues lo he hecho y me sigue pasando exactamente lo mismo...
Por cierto, este es el contenido del archivo
"/etc/apache2/conf.d/owncloud.conf"
<VirtualHost 172.30.7.122:443>
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/owncloud.pem
SSLCertificateKeyFile /etc/apache2/ssl/owncloud.key
DocumentRoot /var/www/owncloud/
ServerName nombre_servidor.dominio
<Directory /var/www/owncloud>
AllowOverride All
order allow,deny
Allow from all
</Directory>
</VirtualHost>
Nota: Por supuesto que en ambos archivos "nombre_servidor.dominio" es
reemplazado por el nombre y dominio que corresponde.
Les agradecería mucho si me pueden dar una mano con este tema.
Saludos, Mauro.
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/545B9FA8...@gmail.com
Mauro Antivero
Nov 6, 2014, 11:40:04 AM11/6/14
to
El 06/11/14 a las 13:30, fernando sainz escibió:
> El día 6 de noviembre de 2014, 17:19, Mauro Antivero
> <mauro.a...@gmail.com> escribió:
> Has probado a poner el dominio / ip en el /etc/hosts.
Si, actualmente lo tengo así:
127.0.0.1 localhost
127.0.1.1 nombre.dominio nombre
Y también probé (sinceramente por probar) ponerlo así:
127.0.0.1 localhost
127.0.1.1 nombre.dominio nombre
172.30.7.122 nombre.dominio nombre
Pero en ambos casos sigue pasando exactamente lo mismo.
Saludos y gracias, Mauro.
>
> S2.
> El día 6 de noviembre de 2014, 17:19, Mauro Antivero
> <mauro.a...@gmail.com> escribió:
Si, actualmente lo tengo así:
127.0.0.1 localhost
127.0.1.1 nombre.dominio nombre
Y también probé (sinceramente por probar) ponerlo así:
127.0.0.1 localhost
127.0.1.1 nombre.dominio nombre
172.30.7.122 nombre.dominio nombre
Pero en ambos casos sigue pasando exactamente lo mismo.
Saludos y gracias, Mauro.
>
> S2.
>
>
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/545BA3E7...@gmail.com
>
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
fernando sainz
Nov 6, 2014, 11:40:05 AM11/6/14
to
Has probado a poner el dominio / ip en el /etc/hosts.
S2.
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Camaleón
Nov 6, 2014, 12:20:03 PM11/6/14
to
El Thu, 06 Nov 2014 13:19:52 -0300, Mauro Antivero escribió:
> Estimados, tengo un servidor con Debian Wheezy 7.7 con una IP privada
> (172.30.7.122/24) corriendo Apache para hacer unas pruebas con OwnCloud.
> He configurado todo para tener acceso solamente por HTTPS y si bien
> parece funcionar correctamente (tengo acceso por HTTPS a la página de
> OwnCloud), cuando reinicio Apache me encuentro con la siguiente
> advertencia la cual me molesta mucho:
>
> service apache2 restart [....] Restarting web server: apache2[Thu Nov 06
> 13:11:31 2014] [error] (EAI 2)Name or service not known: Failed to
> resolve server name for 172.30.7.122 (check DNS) -- or specify an
> explicit ServerName
> ... waiting [Thu Nov 06 13:11:32 2014] [error] (EAI 2)Name or service
> not known: Failed to resolve server name for 172.30.7.122 (check DNS) --
> or specify an explicit ServerName
(...)
> Estimados, tengo un servidor con Debian Wheezy 7.7 con una IP privada
> (172.30.7.122/24) corriendo Apache para hacer unas pruebas con OwnCloud.
> He configurado todo para tener acceso solamente por HTTPS y si bien
> parece funcionar correctamente (tengo acceso por HTTPS a la página de
> OwnCloud), cuando reinicio Apache me encuentro con la siguiente
> advertencia la cual me molesta mucho:
>
> service apache2 restart [....] Restarting web server: apache2[Thu Nov 06
> 13:11:31 2014] [error] (EAI 2)Name or service not known: Failed to
> resolve server name for 172.30.7.122 (check DNS) -- or specify an
> explicit ServerName
> ... waiting [Thu Nov 06 13:11:32 2014] [error] (EAI 2)Name or service
> not known: Failed to resolve server name for 172.30.7.122 (check DNS) --
> or specify an explicit ServerName
Asegúrate de que todas las plantillas de los sitios que tengas
habilitados (sites-enabled) tengan definida esa variable (ServerName) y
de que efectivamente, tu servidor sea capaz de resolver los nombres de
dominio definidos.
Saludos,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Mauro Antivero
Nov 6, 2014, 12:30:03 PM11/6/14
to
El 06/11/14 a las 14:10, Camaleón escibió:
tocado para nada. En este caso la varible ServerName está definida en:
/etc/apache2/apaches2.conf
/etc/apache2/conf.d/owncloud.conf
Lo curioso es que en otro servidor de pruebas que tengo el cual tiene
una IP pública la misma configuración funciona sin problemas.
Sigo buscando pero no logro encontrar que es lo que sucede. Me pregunto
si será un tema de DNS reverso, pero lo raro es que para el servidor que
tengo con una IP pública tampoco tiene un reverso definido.
Saludos y gracias, Mauro.
>
> Saludos,
> El Thu, 06 Nov 2014 13:19:52 -0300, Mauro Antivero escribió:
>
>> Estimados, tengo un servidor con Debian Wheezy 7.7 con una IP privada
>> (172.30.7.122/24) corriendo Apache para hacer unas pruebas con OwnCloud.
>> He configurado todo para tener acceso solamente por HTTPS y si bien
>> parece funcionar correctamente (tengo acceso por HTTPS a la página de
>> OwnCloud), cuando reinicio Apache me encuentro con la siguiente
>> advertencia la cual me molesta mucho:
>>
>> service apache2 restart [....] Restarting web server: apache2[Thu Nov 06
>> 13:11:31 2014] [error] (EAI 2)Name or service not known: Failed to
>> resolve server name for 172.30.7.122 (check DNS) -- or specify an
>> explicit ServerName
>> ... waiting [Thu Nov 06 13:11:32 2014] [error] (EAI 2)Name or service
>> not known: Failed to resolve server name for 172.30.7.122 (check DNS) --
>> or specify an explicit ServerName
> (...)
>
> Asegúrate de que todas las plantillas de los sitios que tengas
> habilitados (sites-enabled) tengan definida esa variable (ServerName) y
> de que efectivamente, tu servidor sea capaz de resolver los nombres de
> dominio definidos.
En sites-enabled solamente tengo el archivo "000-default", el cual no he
>
>> Estimados, tengo un servidor con Debian Wheezy 7.7 con una IP privada
>> (172.30.7.122/24) corriendo Apache para hacer unas pruebas con OwnCloud.
>> He configurado todo para tener acceso solamente por HTTPS y si bien
>> parece funcionar correctamente (tengo acceso por HTTPS a la página de
>> OwnCloud), cuando reinicio Apache me encuentro con la siguiente
>> advertencia la cual me molesta mucho:
>>
>> service apache2 restart [....] Restarting web server: apache2[Thu Nov 06
>> 13:11:31 2014] [error] (EAI 2)Name or service not known: Failed to
>> resolve server name for 172.30.7.122 (check DNS) -- or specify an
>> explicit ServerName
>> ... waiting [Thu Nov 06 13:11:32 2014] [error] (EAI 2)Name or service
>> not known: Failed to resolve server name for 172.30.7.122 (check DNS) --
>> or specify an explicit ServerName
> (...)
>
> Asegúrate de que todas las plantillas de los sitios que tengas
> habilitados (sites-enabled) tengan definida esa variable (ServerName) y
> de que efectivamente, tu servidor sea capaz de resolver los nombres de
> dominio definidos.
tocado para nada. En este caso la varible ServerName está definida en:
/etc/apache2/apaches2.conf
/etc/apache2/conf.d/owncloud.conf
Lo curioso es que en otro servidor de pruebas que tengo el cual tiene
una IP pública la misma configuración funciona sin problemas.
Sigo buscando pero no logro encontrar que es lo que sucede. Me pregunto
si será un tema de DNS reverso, pero lo raro es que para el servidor que
tengo con una IP pública tampoco tiene un reverso definido.
Saludos y gracias, Mauro.
>
> Saludos,
>
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/545BADE7...@gmail.com
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Camaleón
Nov 6, 2014, 12:50:04 PM11/6/14
to
El Thu, 06 Nov 2014 14:20:39 -0300, Mauro Antivero escribió:
> El 06/11/14 a las 14:10, Camaleón escibió:
(...)
> El 06/11/14 a las 14:10, Camaleón escibió:
>>> service apache2 restart [....] Restarting web server: apache2[Thu Nov
>>> 06 13:11:31 2014] [error] (EAI 2)Name or service not known: Failed to
>>> resolve server name for 172.30.7.122 (check DNS) -- or specify an
>>> explicit ServerName
>>> ... waiting [Thu Nov 06 13:11:32 2014] [error] (EAI 2)Name or
>>> service
>>> not known: Failed to resolve server name for 172.30.7.122 (check DNS)
>>> --
>>> or specify an explicit ServerName
>> (...)
>>
>> Asegúrate de que todas las plantillas de los sitios que tengas
>> habilitados (sites-enabled) tengan definida esa variable (ServerName) y
>> de que efectivamente, tu servidor sea capaz de resolver los nombres de
>> dominio definidos.
> En sites-enabled solamente tengo el archivo "000-default", el cual no he
> tocado para nada. En este caso la varible ServerName está definida en:
>
> /etc/apache2/apaches2.conf /etc/apache2/conf.d/owncloud.conf
grep -i servername /etc/apache2/*/*
> Lo curioso es que en otro servidor de pruebas que tengo el cual tiene
> una IP pública la misma configuración funciona sin problemas.
Tú mismo te has respondido: porque puede resolver el dominio/IP ;-)
> Sigo buscando pero no logro encontrar que es lo que sucede. Me pregunto
> si será un tema de DNS reverso, pero lo raro es que para el servidor que
> tengo con una IP pública tampoco tiene un reverso definido.
getent hosts 172.30.7.122
getent hosts 127.0.0.1
Omite los datos sensibles del nombre de dominio pero asegúrate de que el
nombre resuelto concuerde con la variable que hayas definido como
ServerName.
Saludos,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Mauro Antivero
Nov 6, 2014, 1:00:03 PM11/6/14
to
El 06/11/14 a las 14:39, Camaleón escibió:
Perdón, pero no te entiendo :S Mis servidores se llaman "Cloud" (el que
tiene la IP privada) y "Octopus" el que tiene la IP pública. Si hago:
- dig octopus.dominio me devuevle la IP pública que corresponde a dicho
servidor
- dig cloud.dominip me devuelve la IP privada que corresponde a dicho
servidor (172.30.7.122)
Ahora si hago un "dig -x" para cualquiera de las dos IPs no me resuelve
nada, puesto que para ambos casos no están configurados los reversos. A
qué te refieres con que "puede resolver el dominio/IP" (disculpá mi
ignorancia :S).
getent hosts 127.0.0.1
127.0.0.1 localhost
getent hosts 172.30.7.122
(no devuelve nada)
Desde Octopus (servidor con IP pública)
getent hosts 127.0.0.1
127.0.0.1 localhost
getent hosts 172.30.7.122
(no devuelve nada)
Osea que en ambos casos la respuesta es la misma, solo que en el
servidor que tiene la IP pública no obtengo ese mensaje de error al
reiniciar Apache.
Sigo buscando y he encontrado gente que tiene "Apaches" en servidores
con IP privada y les ha salido el mismo mensaje de error, pero en todos
lados dicen que lo han resuelto con la variabla "ServerName nombre.domino"
Algún otro dato de utilidad que les pueda pasar?
Saludos y muchas gracias, Mauro.
tiene la IP privada) y "Octopus" el que tiene la IP pública. Si hago:
- dig octopus.dominio me devuevle la IP pública que corresponde a dicho
servidor
- dig cloud.dominip me devuelve la IP privada que corresponde a dicho
servidor (172.30.7.122)
Ahora si hago un "dig -x" para cualquiera de las dos IPs no me resuelve
nada, puesto que para ambos casos no están configurados los reversos. A
qué te refieres con que "puede resolver el dominio/IP" (disculpá mi
ignorancia :S).
>
>> Sigo buscando pero no logro encontrar que es lo que sucede. Me pregunto
>> si será un tema de DNS reverso, pero lo raro es que para el servidor que
>> tengo con una IP pública tampoco tiene un reverso definido.
> Yo creo que el mensaje que te devuelve es verídico. Manda la salida de:
>
> getent hosts 172.30.7.122
> getent hosts 127.0.0.1
Desde Cloud (servidor con IP 172.30.7.122):
>> Sigo buscando pero no logro encontrar que es lo que sucede. Me pregunto
>> si será un tema de DNS reverso, pero lo raro es que para el servidor que
>> tengo con una IP pública tampoco tiene un reverso definido.
> Yo creo que el mensaje que te devuelve es verídico. Manda la salida de:
>
> getent hosts 172.30.7.122
> getent hosts 127.0.0.1
getent hosts 127.0.0.1
127.0.0.1 localhost
getent hosts 172.30.7.122
(no devuelve nada)
Desde Octopus (servidor con IP pública)
getent hosts 127.0.0.1
127.0.0.1 localhost
getent hosts 172.30.7.122
(no devuelve nada)
Osea que en ambos casos la respuesta es la misma, solo que en el
servidor que tiene la IP pública no obtengo ese mensaje de error al
reiniciar Apache.
Sigo buscando y he encontrado gente que tiene "Apaches" en servidores
con IP privada y les ha salido el mismo mensaje de error, pero en todos
lados dicen que lo han resuelto con la variabla "ServerName nombre.domino"
Algún otro dato de utilidad que les pueda pasar?
Saludos y muchas gracias, Mauro.
>
> Omite los datos sensibles del nombre de dominio pero asegúrate de que el
> nombre resuelto concuerde con la variable que hayas definido como
> ServerName.
>
> Saludos,
>
--
> Omite los datos sensibles del nombre de dominio pero asegúrate de que el
> nombre resuelto concuerde con la variable que hayas definido como
> ServerName.
>
> Saludos,
>
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/545BB5E8...@gmail.com
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Camaleón
Nov 6, 2014, 1:30:04 PM11/6/14
to
El Thu, 06 Nov 2014 14:54:48 -0300, Mauro Antivero escribió:
> El 06/11/14 a las 14:39, Camaleón escibió:
(...)
>>> En sites-enabled solamente tengo el archivo "000-default", el cual no
>>> he tocado para nada. En este caso la varible ServerName está definida
>>> en:
>>>
>>> /etc/apache2/apaches2.conf /etc/apache2/conf.d/owncloud.conf
>> Haz un barrido, que nunca está más:
>>
>> grep -i servername /etc/apache2/*/*
¿Resultado?
>>> Lo curioso es que en otro servidor de pruebas que tengo el cual tiene
>>> una IP pública la misma configuración funciona sin problemas.
>> ^^^^^^^^^^
>>
>> Tú mismo te has respondido: porque puede resolver el dominio/IP ;-)
> Perdón, pero no te entiendo :S Mis servidores se llaman "Cloud" (el que
> tiene la IP privada) y "Octopus" el que tiene la IP pública.
Se pueden llamar como quieras, pero tienen que resolverse y como no usas
un servidor DNS local que relacione los nombres con una IP pues e sistema
estará tirando el archivo /etc/hosts, que es la configuración
predeterminada.
> Si hago:
>
> - dig octopus.dominio me devuevle la IP pública que corresponde a dicho
> servidor
> - dig cloud.dominip me devuelve la IP privada que corresponde a
> dicho servidor (172.30.7.122)
No me explico cómo puedes resolver un dominio local con dig porque es una
herramienta que usa servidores DNS y tu servidor local (cloud.dominio) no
lo resuelve ningún servidor DNS ¿no?
Mira a ver qué te devuelve un "grep hosts /etc/nsswitch.conf".
> Ahora si hago un "dig -x" para cualquiera de las dos IPs no me resuelve
> nada, puesto que para ambos casos no están configurados los reversos. A
> qué te refieres con que "puede resolver el dominio/IP" (disculpá mi
> ignorancia :S).
No creo que apache se esté quejando por la resolución inversa.
>>> Sigo buscando pero no logro encontrar que es lo que sucede. Me
>>> pregunto si será un tema de DNS reverso, pero lo raro es que para el
>>> servidor que tengo con una IP pública tampoco tiene un reverso
>>> definido.
>> Yo creo que el mensaje que te devuelve es verídico. Manda la salida de:
>>
>> getent hosts 172.30.7.122 getent hosts 127.0.0.1
> Desde Cloud (servidor con IP 172.30.7.122):
>
> getent hosts 127.0.0.1 127.0.0.1 localhost
Correcto.
> getent hosts 172.30.7.122 (no devuelve nada)
^^^^^^^^^^^^^^^^^^^^^^^^^
(...)
El segundo comando debería devolverte algo así:
172.30.7.122 cloud.dominio cloud
Saludos,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/pan.2014.11...@gmail.com
> El 06/11/14 a las 14:39, Camaleón escibió:
(...)
>>> En sites-enabled solamente tengo el archivo "000-default", el cual no
>>> he tocado para nada. En este caso la varible ServerName está definida
>>> en:
>>>
>>> /etc/apache2/apaches2.conf /etc/apache2/conf.d/owncloud.conf
>> Haz un barrido, que nunca está más:
>>
>> grep -i servername /etc/apache2/*/*
>>> Lo curioso es que en otro servidor de pruebas que tengo el cual tiene
>>> una IP pública la misma configuración funciona sin problemas.
>> ^^^^^^^^^^
>>
>> Tú mismo te has respondido: porque puede resolver el dominio/IP ;-)
> Perdón, pero no te entiendo :S Mis servidores se llaman "Cloud" (el que
> tiene la IP privada) y "Octopus" el que tiene la IP pública.
un servidor DNS local que relacione los nombres con una IP pues e sistema
estará tirando el archivo /etc/hosts, que es la configuración
predeterminada.
> Si hago:
>
> - dig octopus.dominio me devuevle la IP pública que corresponde a dicho
> servidor
> - dig cloud.dominip me devuelve la IP privada que corresponde a
> dicho servidor (172.30.7.122)
herramienta que usa servidores DNS y tu servidor local (cloud.dominio) no
lo resuelve ningún servidor DNS ¿no?
Mira a ver qué te devuelve un "grep hosts /etc/nsswitch.conf".
> Ahora si hago un "dig -x" para cualquiera de las dos IPs no me resuelve
> nada, puesto que para ambos casos no están configurados los reversos. A
> qué te refieres con que "puede resolver el dominio/IP" (disculpá mi
> ignorancia :S).
>>> Sigo buscando pero no logro encontrar que es lo que sucede. Me
>>> pregunto si será un tema de DNS reverso, pero lo raro es que para el
>>> servidor que tengo con una IP pública tampoco tiene un reverso
>>> definido.
>> Yo creo que el mensaje que te devuelve es verídico. Manda la salida de:
>>
>> getent hosts 172.30.7.122 getent hosts 127.0.0.1
> Desde Cloud (servidor con IP 172.30.7.122):
>
> getent hosts 127.0.0.1 127.0.0.1 localhost
> getent hosts 172.30.7.122 (no devuelve nada)
(...)
El segundo comando debería devolverte algo así:
172.30.7.122 cloud.dominio cloud
Saludos,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Mauro Antivero
Nov 6, 2014, 1:50:03 PM11/6/14
to
El 06/11/14 a las 15:20, Camaleón escibió:
/etc/apache2/conf.d/owncloud.conf: ServerName Cloud.cepanet.com.ar
/etc/apache2/conf.d/owncloud.conf.bkp: ServerName nombre_servidor.dominio
/etc/apache2/mods-available/info.conf:# http://servername/server-info
(requires that mod_info.c be loaded).
/etc/apache2/mods-available/status.conf:# with the URL of
http://servername/server-status
/etc/apache2/mods-enabled/status.conf:# with the URL of
http://servername/server-status
Resulta que algún tonto (osea yo) hizo una copia de respaldo del archivo
"owncloud.conf" y la dejó dentro de "/etc/apache2/conf.d" :S Además,
esta copia de respaldo tenía mal definida la variable "ServerName", y de
ahí venía el error. Saqué esta copia de respaldo de allí y ahora al
hacer un restart no obtengo ningún mensaje, así que problema resuelto!
Sinceramente te agradezco mucho por tu ayuda, no sé cuando me hubiese
dado cuenta sino hacía esto jaja. Entonces, en definitiva el problema
era que tenía un archivo de configuración demás y además este tenía mal
definida la variable "ServerName". Ahora sigo respondiendo entre líneas...
>
>>>> Lo curioso es que en otro servidor de pruebas que tengo el cual tiene
>>>> una IP pública la misma configuración funciona sin problemas.
>>> ^^^^^^^^^^
>>>
>>> Tú mismo te has respondido: porque puede resolver el dominio/IP ;-)
>> Perdón, pero no te entiendo :S Mis servidores se llaman "Cloud" (el que
>> tiene la IP privada) y "Octopus" el que tiene la IP pública.
> Se pueden llamar como quieras, pero tienen que resolverse y como no usas
> un servidor DNS local que relacione los nombres con una IP pues e sistema
> estará tirando el archivo /etc/hosts, que es la configuración
> predeterminada.
Es que hay un DNS local configurado, el cual tiene cargada las IPs de
ambos servidores :S
DNS local configurado, precisamente cuando hago un dig se utiliza este
DNS para resolver.
hosts: files dns
>
>> Ahora si hago un "dig -x" para cualquiera de las dos IPs no me resuelve
>> nada, puesto que para ambos casos no están configurados los reversos. A
>> qué te refieres con que "puede resolver el dominio/IP" (disculpá mi
>> ignorancia :S).
> No creo que apache se esté quejando por la resolución inversa.
Comprendo, efectivamente no era eso.
Por si acaso este es mi /etc/hosts:
127.0.0.1 localhost
127.0.1.1 Cloud.dominio Cloud
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
Saludos, Mauro.
>
> Saludos,
> El Thu, 06 Nov 2014 14:54:48 -0300, Mauro Antivero escribió:
>
>> El 06/11/14 a las 14:39, Camaleón escibió:
> (...)
>
>>>> En sites-enabled solamente tengo el archivo "000-default", el cual no
>>>> he tocado para nada. En este caso la varible ServerName está definida
>>>> en:
>>>>
>>>> /etc/apache2/apaches2.conf /etc/apache2/conf.d/owncloud.conf
>>> Haz un barrido, que nunca está más:
>>>
>>> grep -i servername /etc/apache2/*/*
> ¿Resultado?
Perdón, me lo olvidé! Jajajaja, y acá está la punta del ovillo... Mirá:
>
>> El 06/11/14 a las 14:39, Camaleón escibió:
> (...)
>
>>>> En sites-enabled solamente tengo el archivo "000-default", el cual no
>>>> he tocado para nada. En este caso la varible ServerName está definida
>>>> en:
>>>>
>>>> /etc/apache2/apaches2.conf /etc/apache2/conf.d/owncloud.conf
>>> Haz un barrido, que nunca está más:
>>>
>>> grep -i servername /etc/apache2/*/*
> ¿Resultado?
/etc/apache2/conf.d/owncloud.conf: ServerName Cloud.cepanet.com.ar
/etc/apache2/conf.d/owncloud.conf.bkp: ServerName nombre_servidor.dominio
/etc/apache2/mods-available/info.conf:# http://servername/server-info
(requires that mod_info.c be loaded).
/etc/apache2/mods-available/status.conf:# with the URL of
http://servername/server-status
/etc/apache2/mods-enabled/status.conf:# with the URL of
http://servername/server-status
Resulta que algún tonto (osea yo) hizo una copia de respaldo del archivo
"owncloud.conf" y la dejó dentro de "/etc/apache2/conf.d" :S Además,
esta copia de respaldo tenía mal definida la variable "ServerName", y de
ahí venía el error. Saqué esta copia de respaldo de allí y ahora al
hacer un restart no obtengo ningún mensaje, así que problema resuelto!
Sinceramente te agradezco mucho por tu ayuda, no sé cuando me hubiese
dado cuenta sino hacía esto jaja. Entonces, en definitiva el problema
era que tenía un archivo de configuración demás y además este tenía mal
definida la variable "ServerName". Ahora sigo respondiendo entre líneas...
>
>>>> Lo curioso es que en otro servidor de pruebas que tengo el cual tiene
>>>> una IP pública la misma configuración funciona sin problemas.
>>> ^^^^^^^^^^
>>>
>>> Tú mismo te has respondido: porque puede resolver el dominio/IP ;-)
>> Perdón, pero no te entiendo :S Mis servidores se llaman "Cloud" (el que
>> tiene la IP privada) y "Octopus" el que tiene la IP pública.
> Se pueden llamar como quieras, pero tienen que resolverse y como no usas
> un servidor DNS local que relacione los nombres con una IP pues e sistema
> estará tirando el archivo /etc/hosts, que es la configuración
> predeterminada.
ambos servidores :S
>
>> Si hago:
>>
>> - dig octopus.dominio me devuevle la IP pública que corresponde a dicho
>> servidor
>> - dig cloud.dominip me devuelve la IP privada que corresponde a
>> dicho servidor (172.30.7.122)
> No me explico cómo puedes resolver un dominio local con dig porque es una
> herramienta que usa servidores DNS y tu servidor local (cloud.dominio) no
> lo resuelve ningún servidor DNS ¿no?
SI, como decía más arriba, perdón que no lo expliqué antes, pero hay un
>> Si hago:
>>
>> - dig octopus.dominio me devuevle la IP pública que corresponde a dicho
>> servidor
>> - dig cloud.dominip me devuelve la IP privada que corresponde a
>> dicho servidor (172.30.7.122)
> No me explico cómo puedes resolver un dominio local con dig porque es una
> herramienta que usa servidores DNS y tu servidor local (cloud.dominio) no
> lo resuelve ningún servidor DNS ¿no?
DNS local configurado, precisamente cuando hago un dig se utiliza este
DNS para resolver.
>
> Mira a ver qué te devuelve un "grep hosts /etc/nsswitch.conf".
Pues bien, ni idea que hace este comando, pero esta es la salida:
> Mira a ver qué te devuelve un "grep hosts /etc/nsswitch.conf".
hosts: files dns
>
>> Ahora si hago un "dig -x" para cualquiera de las dos IPs no me resuelve
>> nada, puesto que para ambos casos no están configurados los reversos. A
>> qué te refieres con que "puede resolver el dominio/IP" (disculpá mi
>> ignorancia :S).
> No creo que apache se esté quejando por la resolución inversa.
>
>>>> Sigo buscando pero no logro encontrar que es lo que sucede. Me
>>>> pregunto si será un tema de DNS reverso, pero lo raro es que para el
>>>> servidor que tengo con una IP pública tampoco tiene un reverso
>>>> definido.
>>> Yo creo que el mensaje que te devuelve es verídico. Manda la salida de:
>>>
>>> getent hosts 172.30.7.122 getent hosts 127.0.0.1
>> Desde Cloud (servidor con IP 172.30.7.122):
>>
>> getent hosts 127.0.0.1 127.0.0.1 localhost
> Correcto.
>
>> getent hosts 172.30.7.122 (no devuelve nada)
> ^^^^^^^^^^^^^^^^^^^^^^^^^
>
> (...)
>
> El segundo comando debería devolverte algo así:
>
> 172.30.7.122 cloud.dominio cloud
Pues no me devuelve absolutamente nada :S
>>>> Sigo buscando pero no logro encontrar que es lo que sucede. Me
>>>> pregunto si será un tema de DNS reverso, pero lo raro es que para el
>>>> servidor que tengo con una IP pública tampoco tiene un reverso
>>>> definido.
>>> Yo creo que el mensaje que te devuelve es verídico. Manda la salida de:
>>>
>>> getent hosts 172.30.7.122 getent hosts 127.0.0.1
>> Desde Cloud (servidor con IP 172.30.7.122):
>>
>> getent hosts 127.0.0.1 127.0.0.1 localhost
> Correcto.
>
>> getent hosts 172.30.7.122 (no devuelve nada)
> ^^^^^^^^^^^^^^^^^^^^^^^^^
>
> (...)
>
> El segundo comando debería devolverte algo así:
>
> 172.30.7.122 cloud.dominio cloud
Por si acaso este es mi /etc/hosts:
127.0.0.1 localhost
127.0.1.1 Cloud.dominio Cloud
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
Saludos, Mauro.
>
> Saludos,
>
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/545BC29C...@gmail.com
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Camaleón
Nov 7, 2014, 10:20:03 AM11/7/14
to
El Thu, 06 Nov 2014 15:49:00 -0300, Mauro Antivero escribió:
> El 06/11/14 a las 15:20, Camaleón escibió:
(...)
>>>> grep -i servername /etc/apache2/*/*
>> ¿Resultado?
> Perdón, me lo olvidé! Jajajaja, y acá está la punta del ovillo... Mirá:
>
> /etc/apache2/conf.d/owncloud.conf: ServerName Cloud.cepanet.com.ar
> /etc/apache2/conf.d/owncloud.conf.bkp: ServerName
> nombre_servidor.dominio /etc/apache2/mods-available/info.conf:#
> http://servername/server-info (requires that mod_info.c be loaded).
> /etc/apache2/mods-available/status.conf:# with the URL of
> http://servername/server-status /etc/apache2/mods-enabled/status.conf:#
> with the URL of http://servername/server-status
>
> Resulta que algún tonto (osea yo) hizo una copia de respaldo del archivo
> "owncloud.conf" y la dejó dentro de "/etc/apache2/conf.d" :S Además,
> esta copia de respaldo tenía mal definida la variable "ServerName", y de
> ahí venía el error. Saqué esta copia de respaldo de allí y ahora al
> hacer un restart no obtengo ningún mensaje, así que problema resuelto!
Ah, vaya. Pues qué puñetero es el apache ¿no? :-)
Porque la plantilla de backup no está dentro de los sitios habilitados
(sites-enabled) así que no tendría que haberla tenido en cuenta.
> Sinceramente te agradezco mucho por tu ayuda, no sé cuando me hubiese
> dado cuenta sino hacía esto jaja. Entonces, en definitiva el problema
> era que tenía un archivo de configuración demás y además este tenía mal
> definida la variable "ServerName". Ahora sigo respondiendo entre
> líneas...
Bien está lo que bien acaba. Por cierto, pregunta de curiosidad ¿por qué
te has decidido por OwnCloud?
>> Se pueden llamar como quieras, pero tienen que resolverse y como no
>> usas un servidor DNS local que relacione los nombres con una IP pues e
>> sistema estará tirando el archivo /etc/hosts, que es la configuración
>> predeterminada.
> Es que hay un DNS local configurado, el cual tiene cargada las IPs de
> ambos servidores :S
Ahhh, amigo, eso lo cambia todo (y eso explica por qué dig te devolvía
una respuesta correcta).
En el caso de que el error que te daba hubiera sido "real" (es decir, que
no se hubiera debido a una plantilla de configuración que no debía estar)
tendrías que haberte fijado en si la configuración del servidor DNS para
el dominio/IP que te daba problemas era correcta, ya que al usar un
servidor de nombre local para resolver, el archivo /etc/hosts hubiera
sido irrelevante.
>> Mira a ver qué te devuelve un "grep hosts /etc/nsswitch.conf".
> Pues bien, ni idea que hace este comando, pero esta es la salida:
>
> hosts: files dns
Ese archivo (nsswitch.conf) define varias cosas, pero entre ellas
determina qué tipo de sistema de resolución va a usar la función
"gethostbyname" del sistema operativo. La variable "hosts" que tienes
configurada dice que primero mirará en el archivo "/etc/hosts" y después
consultará el servidor dns en el caso la primera consulta devuelva un
error.
>>> getent hosts 172.30.7.122 (no devuelve nada)
>> ^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> (...)
>>
>> El segundo comando debería devolverte algo así:
>>
>> 172.30.7.122 cloud.dominio cloud
> Pues no me devuelve absolutamente nada :S
En tu caso es normal porque usas un servidor dns para resolver el dominio
local, que es lo más correcto, aunque la mayoría de las veces se opta por
la solución facilona y se define el equipo local en el archivo "/etc/
hosts" para tranquilizar al servidor apache :-)
> Por si acaso este es mi /etc/hosts:
>
> 127.0.0.1 localhost
> 127.0.1.1 Cloud.dominio Cloud
(...)
Aunque ya no tiene importancia, en el caso de que no usaras un servidor
dns y quisieras definir el equipo en ese archivo, tendrías que usar la
misma IP que tienes configurada en el host virtual de apache, es decir,
tendrías que usar:
***
172.30.7.122 cloud.dominio cloud
***
Saludos,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/pan.2014.11...@gmail.com
> El 06/11/14 a las 15:20, Camaleón escibió:
(...)
>>>> grep -i servername /etc/apache2/*/*
>> ¿Resultado?
> Perdón, me lo olvidé! Jajajaja, y acá está la punta del ovillo... Mirá:
>
> /etc/apache2/conf.d/owncloud.conf: ServerName Cloud.cepanet.com.ar
> /etc/apache2/conf.d/owncloud.conf.bkp: ServerName
> nombre_servidor.dominio /etc/apache2/mods-available/info.conf:#
> http://servername/server-info (requires that mod_info.c be loaded).
> /etc/apache2/mods-available/status.conf:# with the URL of
> http://servername/server-status /etc/apache2/mods-enabled/status.conf:#
> with the URL of http://servername/server-status
>
> Resulta que algún tonto (osea yo) hizo una copia de respaldo del archivo
> "owncloud.conf" y la dejó dentro de "/etc/apache2/conf.d" :S Además,
> esta copia de respaldo tenía mal definida la variable "ServerName", y de
> ahí venía el error. Saqué esta copia de respaldo de allí y ahora al
> hacer un restart no obtengo ningún mensaje, así que problema resuelto!
Porque la plantilla de backup no está dentro de los sitios habilitados
(sites-enabled) así que no tendría que haberla tenido en cuenta.
> Sinceramente te agradezco mucho por tu ayuda, no sé cuando me hubiese
> dado cuenta sino hacía esto jaja. Entonces, en definitiva el problema
> era que tenía un archivo de configuración demás y además este tenía mal
> definida la variable "ServerName". Ahora sigo respondiendo entre
> líneas...
te has decidido por OwnCloud?
>> Se pueden llamar como quieras, pero tienen que resolverse y como no
>> usas un servidor DNS local que relacione los nombres con una IP pues e
>> sistema estará tirando el archivo /etc/hosts, que es la configuración
>> predeterminada.
> Es que hay un DNS local configurado, el cual tiene cargada las IPs de
> ambos servidores :S
una respuesta correcta).
En el caso de que el error que te daba hubiera sido "real" (es decir, que
no se hubiera debido a una plantilla de configuración que no debía estar)
tendrías que haberte fijado en si la configuración del servidor DNS para
el dominio/IP que te daba problemas era correcta, ya que al usar un
servidor de nombre local para resolver, el archivo /etc/hosts hubiera
sido irrelevante.
>> Mira a ver qué te devuelve un "grep hosts /etc/nsswitch.conf".
> Pues bien, ni idea que hace este comando, pero esta es la salida:
>
> hosts: files dns
determina qué tipo de sistema de resolución va a usar la función
"gethostbyname" del sistema operativo. La variable "hosts" que tienes
configurada dice que primero mirará en el archivo "/etc/hosts" y después
consultará el servidor dns en el caso la primera consulta devuelva un
error.
>>> getent hosts 172.30.7.122 (no devuelve nada)
>> ^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> (...)
>>
>> El segundo comando debería devolverte algo así:
>>
>> 172.30.7.122 cloud.dominio cloud
> Pues no me devuelve absolutamente nada :S
local, que es lo más correcto, aunque la mayoría de las veces se opta por
la solución facilona y se define el equipo local en el archivo "/etc/
hosts" para tranquilizar al servidor apache :-)
> Por si acaso este es mi /etc/hosts:
>
> 127.0.0.1 localhost
> 127.0.1.1 Cloud.dominio Cloud
Aunque ya no tiene importancia, en el caso de que no usaras un servidor
dns y quisieras definir el equipo en ese archivo, tendrías que usar la
misma IP que tienes configurada en el host virtual de apache, es decir,
tendrías que usar:
***
172.30.7.122 cloud.dominio cloud
***
Saludos,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Maykel Franco
Nov 7, 2014, 10:30:04 AM11/7/14
to
Esto me interesa mmm. Crees que hay otra alternativa mejor? Por algo lo preguntas.
Saludos.
Camaleón
Nov 7, 2014, 11:20:04 AM11/7/14
to
El Fri, 07 Nov 2014 16:21:50 +0100, Maykel Franco escribió:
(grr.... grrr.....)
> El 07/11/2014 16:12, "Camaleón" <noel...@gmail.com> escribió:
>>
>> El Thu, 06 Nov 2014 15:49:00 -0300, Mauro Antivero escribió:
>>
>> > El 06/11/14 a las 15:20, Camaleón escibió:
>>
>> (...)
>>
>> >>>> grep -i servername /etc/apache2/*/*
>> >> ¿Resultado?
>> > Perdón, me lo olvidé! Jajajaja, y acá está la punta del ovillo...
>> > Mirá:
>> >
>> > /etc/apache2/conf.d/owncloud.conf: ServerName Cloud.cepanet.com.ar
>> > /etc/apache2/conf.d/owncloud.conf.bkp: ServerName
>> > nombre_servidor.dominio
(...)
>> Bien está lo que bien acaba. Por cierto, pregunta de curiosidad ¿por
>> qué te has decidido por OwnCloud?
>
> Esto me interesa mmm. Crees que hay otra alternativa mejor? Por algo lo
> preguntas.
A mí no me mires que yo también lo pregunto precisamente porque lo
desconozco :-)
Sólo conozco un par de opciones más (Pydio y SparkleShare) pero como todo
el mundo instala ownCloud, pues por eso preguntaba, por si tuviera alguna
funcionalidad o característica que lo hace único y deseable.
(grr.... grrr.....)
> El 07/11/2014 16:12, "Camaleón" <noel...@gmail.com> escribió:
>>
>> El Thu, 06 Nov 2014 15:49:00 -0300, Mauro Antivero escribió:
>>
>> > El 06/11/14 a las 15:20, Camaleón escibió:
>>
>> (...)
>>
>> >>>> grep -i servername /etc/apache2/*/*
>> >> ¿Resultado?
>> > Perdón, me lo olvidé! Jajajaja, y acá está la punta del ovillo...
>> > Mirá:
>> >
>> > /etc/apache2/conf.d/owncloud.conf: ServerName Cloud.cepanet.com.ar
>> > /etc/apache2/conf.d/owncloud.conf.bkp: ServerName
>> > nombre_servidor.dominio
>> Bien está lo que bien acaba. Por cierto, pregunta de curiosidad ¿por
>> qué te has decidido por OwnCloud?
>
> Esto me interesa mmm. Crees que hay otra alternativa mejor? Por algo lo
> preguntas.
desconozco :-)
Sólo conozco un par de opciones más (Pydio y SparkleShare) pero como todo
el mundo instala ownCloud, pues por eso preguntaba, por si tuviera alguna
funcionalidad o característica que lo hace único y deseable.
0 new messages