opensuse
[Arriba] [Todas las Listas]

Re: [opensuse] Qué 127.0.1.1 malo?

To: opensuse@xxxxxxxxxxxx
Subject: Re: [opensuse] Qué 127.0.1.1 malo?
From: lynn <lynn@xxxxxxxxxxxx>
Date: Sun, 01 Apr 2012 09:06:04 +0200
Delivered-to: opensuse@xxxxxxxxxxxxxxxxxxx
Delivery-date: Sun, 01 Apr 2012 03:06:53 -0400
Envelope-to: traductor@xxxxxxxxxxx
In-reply-to: <4F775380.8040606@antonaylward.com>
List-archive: <http://lists.opensuse.org/opensuse/>
List-help: <mailto:opensuse+help@opensuse.org>
List-owner: <mailto:opensuse+owner@opensuse.org>
List-post: <mailto:opensuse@opensuse.org>
List-subscribe: <mailto:opensuse+subscribe@opensuse.org>
List-unsubscribe: <mailto:opensuse+unsubscribe@opensuse.org>
Mailing-list: contact opensuse+help@xxxxxxxxxxxx; run by mlmmj
References: <4F749D25.7080107@steve-ss.com> <4F74AD37.4050304@antonaylward.com> <4F75950D.6020203@steve-ss.com> <4F75A8A8.9030102@antonaylward.com> <4F75CE13.6050706@telefonica.net> <4F75EA66.20304@antonaylward.com> <4F76095B.1080801@steve-ss.com> <4F7631DF.1000603@antonaylward.com> <4F76AF84.1050805@steve-ss.com> <4F76FA67.4090507@antonaylward.com> <4F772477.3080002@steve-ss.com> <4F7737F2.5000903@antonaylward.com> <4F7744CF.9030204@steve-ss.com> <4F775380.8040606@antonaylward.com>
User-agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120215 Thunderbird/10.0.2
*El 31/03/12 20:57, Anton *Aylward *escribió:
*lynn dijo el siguiendo en 03/31/2012 01:54 PM:
En 03/31/2012 06:59 PM, Anton *Aylward escribió:
*lynn dijo el siguiendo en 03/31/2012 11:36 AM:

 necesito un *PTR para cada ordenador en el *lan?
Si hubiste *ddns laborable entonces sería hecho 'coche-*magically'.


Sí. He *ddns laborable. La zona de delantero es actualizada por *Samba4 cuando las máquinas nuevas son *allocated IP, unir el ámbito *etc. Justo no tuve un inverso *lookup zona.

Supongo que la prueba
sería para sacar el
   127.0.1.1 *hostname.*fqdn *hostname
Entrada en /*etc/anfitriones en el cliente y ver si podemos todavía *authenticate.

No soy seguro que de hecho sería una prueba.
Ve más tarde ....

hay dos maneras a la lata consigue sus direcciones inversas para trabajar.
El primero es para utilizar 'dinámico *dns' donde el *DHCP *server dice el DNS
*server que lo ha asignado una dirección y suministra los detalles que
el DNS *server puede ahora hubo fuera en respuesta a consultas.

Pienso que aquello es lo que está pasando porque puedes ver el *KDC recibir peticiones de IP que ha sido *allocated *via *DHCP _y_ correctamente *lookup su *Kerberos máquina$/*fqdn llave correctamente para *authentication.

Sí. Aquello es lo que tenemos. Aquello es lo que el *samba4 *guys añadió para ligar9 a lo
Fue el *Samba *guys?
Pensé *DDNS (RFC2136 *et *al [3007, 4033, 4034, 4035]) data atrás a 1997
y era fuera del ISC editado por el *proverbial Señor *Vixie :-)

Sí, Microsoft y Anuncio integrados *DDNS y traído en la versión
modificada de *kerberos, pero que todavía no lo hace un *SAMBA iniciativa.

Puedes experimento a mano añadiendo registros del *CLI con '*nsupdate'.
Eran los que pusieron él *dlz código a ligar para hacerlo trabaja contra ANUNCIO.

Te es corriendo ANUNCIO?  Tienes un maestro de ámbito del Microsoft que corre ANUNCIO o te
es todo Linux en el núcleo y justo clientes de Ventanas?


Sí estamos corriendo ANUNCIO. *Samba4 _es_ ANUNCIO. El *schema incluye *rfc2703. Nuestros usuarios tienen el *posixAccount y *posixGroup objetos que son definidos en el *m$ ANUNCIO *schema. (Hecho público *via el *Samba *vs *m$ el Tribunal europeo que gobierna último año)

lo consigue para hacer el dinámico actualiza. Tenemos nuestro ganar7 y *linux los clientes que
utilizan el *dhcp *server.
Aquello es el *server corriendo bajo Linux?
12.1 *server corriendo el *Samba4 implementación de ANUNCIO para servir ambos ganan7 y clientes
de Linux.

Justo clientes de Ventanas entonces ...

No. Nuestro *lan consiste de Linux y ventanas con #uno 12.1 *server. Principalmente 12.1 y ganar7 con algún *Ubuntu y *xp clientes para mantener el *punters feliz.


Sé el código he visto ha *kerberos llamando "*krb_*mk_*req()" para conseguir
un ticket y que necesita el *FQDN como parámetro.


*Kerberos Necesita no sólo a *authenticate el usuario pero también las máquinas en el *lan. Cuándo yo *logon, tanto yo y mi ordenador tenemos que *authenticate. Si pido un archivo entonces ambos yo y el *fileserver tiene que *authenticate. Esto es por qué el *dns es crucial con *Kerberos.

Ahora la cuestión soy dejado con es esto.  Es la máquina arriba de y corriendo,
lo tiene conseguido su dirección de IP del *DHCP *server?

Sí. En este punto el *dlz parte de DNS *grabs lo. Ahora, sólo mi delantero es actualizado así que mi zona inversa está yendo para saber nada sobre el actualizar lo es?

  Si tiene y hay
un inverso *lookup que da su *FQDN que satisfará el *kerberos
ticket *server, entonces bien.

Mi sugerencia es para utilizar el 'trampa' sugerí.
Si esto es una clase-de *static *setup de modo que la dirección de MAC de aquel
*workstation dice *DHCP qué dirección de IP para entregar fuera, entonces eres seguro a código
duro el material inverso dentro; parece el *YAST la interfaz dejará
aquello.  Oh, y conseguir librado de todo el *IPV6 material mientras eres sobre él.

Hará.






Ningún aquello es bien. El error único ahora es aquí:
Mar 31 17:25:44 *hh3 nombrado[2483]: empezando LIGA 9.8.1-*P1 -*u nombró
*Info no *err




Mar 31 17:25:44 *hh3 nombrado[2483]: leyendo construido-llaves confiadas dentro de archivo
'/*etc/liga.Llaves'
Sí pero recuerdo no hay real una llave, allí , es allí?


No. Justo un archivo vacío para conseguir librado de él mensaje de error sobre el archivo no encontrado.

Construyendo el clave e incluyéndolo en DNS/*DHCP era una opción en aquellas
pantallas en el *blog que no tomaste.  Quizás tendrías que tener ..


Sí, conseguía aquello.
Pero aquello es donde espera ver ellos llaves cuándo su haciendo el *DDNS material.




Sí, pero a no ser que contiene el *crypto la llave compartida por *DHCP y DNS entonces
*DDNS no trabajará.  Esto tendría que haber sido generado por *YAST.  Su un de las
opciones, gusta eliminar *IPv6, que tendrías que haber puesto.
En mi caso, el *ddns es manejado en otro lugar así que ningún problema.

Sí, pero parece sólo para los clientes de Ventanas.
Con el *linux los clientes arriba de ti tendrían que ser capaces de hacer un inverso *lookup para
cada cual de ellos.

Cómo venido el trabajo de clientes de las ventanas *OK. Qué  tienen que nosotros  no?
Realmente quieres utilizar las herramientas (cava, anfitrión, *nslookup) para verter la totalidad
del dentro-delantero de memoria y mesas inversas - un 'transferencia de zona'.

Según
*http://*docstore.*mik.*ua/*orelly/*networking_2*ndEd/*tcp/*appc_01.*htm
<Cita>
SIGINT: las Causas nombradas para verter su *cache a vertederonombrado.*db. El archivo de vertedero
contiene todo de la información de ámbito que el nombre local *server sabe.
El archivo empieza con la raíz *servers y marcas de cada ámbito bajo
la raíz que el local *server sabe cualquier cosa aproximadamente.
</Citar>

Probar aquello - después de todo las máquinas son 'arriba y *runnning' y ver si el
delantero y las entradas inversas están siendo inyectados.

Más cercano a *undestanding. *Thanks Otra vez.
*L *x
--
A *unsubscribe, *e-correo: *opensuse+unsubscribe@xxxxxxxxxxxx
para contactar el dueño, *e-correo: *opensuse+owner@xxxxxxxxxxxx


El 31/03/12 20:57, Anton Aylward escribió:
lynn said the following on 03/31/2012 01:54 PM:
On 03/31/2012 06:59 PM, Anton Aylward wrote:
lynn said the following on 03/31/2012 11:36 AM:

Do I need a PTR for each computer on the lan?
If you had ddns working then it would be done 'auto-magically'.


Yes. I have ddns working. The forward zone is updated by Samba4 when new machines are allocated IP's, join the domain etc. I just didn't have a reverse lookup zone.

I suppose the
test would be to remove the
   127.0.1.1 hostname.fqdn hostname
entry in /etc/hosts on the client and see if we can still authenticate.

I'm not sure that would actually be a test.
See later ....

There are two ways to can get their reverse addresses to work.
The first is to use 'dynamic dns' where the DHCP server tells the DNS
server that it has assigned an address and supplies the details which
the DNS server can now had out in response to queries.

I think that is what is happening because you can see the KDC receive requests from IP's which have been allocated via DHCP _and_ correctly lookup their Kerberos machine$/fqdn key correctly for authentication.

Yes. That's what we have. that's what the samba4 guys added to bind9 to
Was it the Samba guys?
I thought DDNS (RFC2136 et al [3007, 4033, 4034, 4035]) dates back to
1997 and was out of ISC edited by the proverbial Mr Vixie :-)

Yes, Microsoft and Ad integrated DDNS and brought in the modified
version of kerberos, but that still doesn't make it a SAMBA initiative.

You can experiment manually adding records from the CLI with 'nsupdate'.
They were the ones who put he dlz code into bind to make it work against AD.

Are you running AD?  You have a Microsoft domain master running AD or
are you all Linux at the core and just Windows clients?


Yes we are running AD. Samba4 _is_ AD. The schema includes rfc2703. Our users have the posixAccount and posixGroup objects which are defined in the m$ AD schema. (made public via the Samba vs m$ European Court ruling last year)

get it to do the dynamic updates. We have our win7 and linux clients
using the dhcp server.
That's the server running under Linux?
12.1 server running the Samba4 AD implementation to serve both win7 and
Linux clients.

Just Windows clients then ...

No. Our lan consists of Linux and windows with a 12.1 server. Mainly 12.1 and win7 with some Ubuntu and xp clients to keep the punters happy.


I do know the code I've seen has kerberos calling "krb_mk_req()" to get
a ticket and that needs the FQDN as a parameter.


Kerberos needs not only to authenticate the user but also the machines on the lan. When I logon, both I and my computer have to authenticate. If I request a file then both I and the fileserver have to authenticate. This is why the dns is crucial with Kerberos.

Now the question I'm left with is this.  Is the machine up and running,
has it got its IP address from the DHCP server?

Yes. At this point the dlz part of DNS grabs it. Now, only my forward is updated so my reverse zone is going to know nothing about the update is it?

  If it has and there is
a reverse lookup that gives its FQDN that will satisfy the kerberos
ticket server, then fine.

My suggestion is to use the 'cheat' I suggested.
If this is a sort-of static setup so that the MAC address of that
workstation tells DHCP what IP address to hand out, then you are safe to
hard code the reverse stuff in; it seems the YAST interface will allow
that.  Oh, and get rid of all the IPV6 stuff while you're about it.

Will do.






No that's fine. The only error now is here:
Mar 31 17:25:44 hh3 named[2483]: starting BIND 9.8.1-P1 -u named
Info not err




Mar 31 17:25:44 hh3 named[2483]: reading built-in trusted keys from file
'/etc/bind.keys'
Yes but I recall there isn't actual a key, there , is there?


No. Just an empty file to get rid of he error message about the file not found.

Building the key and including it in DNS/DHCP was an option on those
screens at the blog which you didn't take.  Perhaps you should have ..


Yes, I got that.
But that's where it expect to see they keys when its doing the DDNS stuff.




Yes, but unless it contains the crypto key shared by DHCP and DNS then
DDNS won't work.  This should have been generated by YAST.  Its one of
the options, like deleting IPv6, that you should have set.
In my case, the ddns is handled elsewhere so no problem.

Yes, but it seems only for the Windows clients.
With the linux clients up you should be able to do a reverse lookup for
each of them.

How come the windows clients work OK. What do they have that we don't?
You really want to use the tools (dig, host, nslookup) to dump the whole
of the in-memory forward and reverse tables - a 'zone transfer'.

According to
http://docstore.mik.ua/orelly/networking_2ndEd/tcp/appc_01.htm
<quote>
SIGINT: Causes named to dump its cache to named_dump.db. The dump file
contains all of the domain information that the local name server knows.
The file begins with the root servers and marks off every domain under
the root that the local server knows anything about.
</quote>

Try that - after all the machines are 'up and runnning' and see if the
forward and reverse entries are being injected.

Nearer to undestanding. Thanks again.
L x
--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx


<Anterior por Tema] Tema Actual [Siguiente por Tema>