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: Anton Aylward <opensuse@xxxxxxxxxxxxxxxx>
Date: Sun, 01 Apr 2012 17:32:26 -0400
Delivered-to: opensuse@xxxxxxxxxxxxxxxxxxx
Delivery-date: Sun, 01 Apr 2012 17:33:20 -0400
Dkim-signature: v=1; a=rsa-sha1; c=relaxed; d=antonaylward.com; h= message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; s= antonaylward.com; bh=4Lotw79VMN3l37T+Gg4WZdiX3v4=; b=Vvidw/gah+L Sy0bSxWn/T4zrn8crwswMRT3CH03p0/AVrZC0NWO7KQK/QcbEUBxE5kzrlQryxqM bVOeRHbSvCBM030V5jHVpXpb0pBOltLLeLt+WKZZP4UlHgmuDtkgUQ1z65oLYW6k iI5ljro79cRgOzcbCuKtoMb4UtvdGNDk=
Domainkey-signature: a=rsa-sha1; c=nofws; d=antonaylward.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s= antonaylward.com; b=cUwo8xxWnuREPAqeUwBJrBITGxm2l8fZaDY4190ksd+d XPpghNeciziLskOGfN15xMU8KcMPkJXcRwX5yQo5+ko9ykblntrhUb0AT2SO+xr2 UqogLy9iVLBYLLG+ISmKAxqHbBz/o3dwTv3zk7XbcJiNY/3x3C+Vd+DgBd5/Z0E=
Envelope-to: traductor@xxxxxxxxxxx
In-reply-to: <4F78BD7B.7000500@steve-ss.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
Organization: SI
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> <4F77FE5C.90401@steve-ss.com> <4F785668.30807@antonaylward.com> <4F78BD7B.7000500@steve-ss.com>
User-agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.1) Gecko/20120209 Firefox/10.0.1 Thunderbird/10.0.1
*lynn Dijo el siguiendo en 04/01/2012 04:41 PM:

>> A correctamente mirada arriba de *FQDN de sólo una IP requiere trata el DNS correctamente
>> implementa inverso *lookup.  Nosotros'*ve estableció no tienes completo
>> y *accurate mesas inversas.
>>
>> Te #poder complacer dilucidar.
>>
> No tengo inverso *lookup. 

Entonces no puedo ver cómo puedes esperar esto para trabajar correctamente.

Y no, *spoofing *Kerberos por *fiddling con /*etc/anfitriones 127.0.0.1 entrada no
está "trabajando correctamente".  Carlos es bastante bien, que es
*localhost.*localdomain Y no puede ser cualquier cosa más sin romper otro
*fundamentals.  Cambiándolo al *fqdn para conseguir alrededor de la ausencia de inverso
*lookup es *subverting *Kerberos.

> La zona de delantero es creada cuándo empiezo 
> liga. 

*Picky: No, cuándo empiezas lo liga lee el *config archivo y construye su
mapa interno de modo que puede *respond a consultas sobre la zona de delantero.

Necesitas tener aquella zona definida y todo el *static dispositivos en él
(*servers, *firewalls, *routers) cuando registros de recurso definido (*RRs)

*DHCP añadirá y sacar más *RRs - si tienes la cosa montó
correctamente y *DHCP sabe sobre el compartido *cypto la llave necesitada para comunicaciones
seguras.

> Consigue actualizado cuándo un cliente nuevo (Linux o ventanas) botas o une
> el ámbito. Para *ddns lo tiene un *tsig que es un *Kerberos *keytab. El 
> *keytab fue producido cuándo el ANUNCIO era primer *provisioned. Yo *posted nombró.*conf Hace unos cuantos correos. También tengo un *static zona inversa. La cosa 
> única que lo impide demasiado de ser incluido en el *ddns es que no sé cómo para generar un *keytab para él. Esto es donde el *Samba *guys 
> ha cambiado el ligar *innards.

Prueba leer
*http://www.oceanwave.com/técnico-recursos/*unix-*admin/*nsupdate.*html

Recuerdas aquello liga *complained sobre un archivo y tú lo crearon (vacío)
con 'tacto'?  Bien adivinar qué....




>>>> 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)
>>
>> pienso que estamos hablando en cruz [los propósitos o yo necesitan un actualizar.
>> Pensé *SAMBA actuaba como Controlador de Ámbito y que el ANUNCIO era
>> el *database, posiblemente (pero no siempre) implementado por *LDAP.
>>
>> ANUNCIO = Directorio Activo, un *dynamically mantuvo *database, un servicio
>> de directorio que carreras en el Controlador de Ámbito y DNS de necesidades, *Kerberos y *LDAP
>> para apoyarlo.
>>
>> Pensé *SAMBA era más que justo ANUNCIO.
>>
> *Samba4 es un controlador de ámbito de las ventanas. Consiste de un totalmente 
> Linux-*ified ANUNCIO. Tiene su propio construido en *KDC y *LDAP *server.
> 
> Pronto, tendrá su DNS propio *server también. Ya tiene su DNS 
> laborable propio *server pero irónicamente lo trabajos únicos para delantero *ddns en 
> el momento.

Mantienes *asserting que, pero puede das la referencia complace.





> 
>>
>>> *Kerberos Necesita no sólo a *authenticate el usuario pero también las máquinas
>>> en el *lan.
>> Aquello es por qué *DNS implementado* correctamente es crucial con *Kerberos.
>>
>> Si el código puede no  un lleno *backward-para-*ward-*backward *verification de la
>> IP/*FQDN del **authoritative* (y presumiblemente asegurado) servicio
>> de DNS entonces el *fallback al /*etc/los anfitriones es un agujero de seguridad.  El
>> usuario en el control de la máquina de cliente puede poner cualquier cosa él (o ella) gusta
>> a /*etc/anfitriones y tan *spoof la identificación.
>>
> La Raíz única tiene acceso a /*etc/anfitriones en nuestro *lan.

*Picky: Su no significado para ser accedido del LAN, su significado para
ser accedido de programas locales, incluyendo unos que no están corriendo como
raíz.  Tendría que ser 0644/raíz:raíz.

Carlos, otros,  te preocupas a *verify aquello y explicar a *Lynn por qué
/*etc/los anfitriones necesita ser *readable por todo el mundo.

Control /*etc/permisos


>>>> 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?
>>
>> No sé.  En todos los sistemas he trabajado con él *boils abajo al
>> *DHCP *server diciendo el DNS *server.
>>
>> La dirección es entregada fuera de después de la máquina de Linux es chutada, mucho tiempo antes del
>> *SAMBA el cliente viene arriba, así que el *SAMBA el lado de cosas tendría que tener
>> nada para hacer con él.  Todo este *DDNS tendría que trabajar a toda costa de la
>> presencia de *SAMBA, *Kerberos, *YP/NIS, o NFS.  *SAMBA No es un requisito
>> para HP/de AIX/de Linux/de UNIX-*UX/DG-*UX/*Solaris-las redes únicas y yo lo han tenido
>> corriendo en aquella clase de poner.
> 
> *Kerberos Tiene que *authenticate el *dns *server antes de que puede hacer cualquier cosa en 
> el *lan. 

Complacer explicar.
Te es diciendo que antes de que el DNS *server el programa que escucha en puerto 53
en el *server la máquina puede *respond a peticiones de DNS de la máquina algún
*Kerberos *authentication tiene que tomar encaje?  De qué y por qué?

Qué sobre el *DHCP *server el programa que corre en el *server ... ?



> El *KDC es suministrado por *Samba tan *Samba tiene que ser arriba de antes de cualquier 
> *ddns tiene lugar. 

No, que no hace sentido.

Tomar todo el material de Ventanas de vuestro LAN, imposibilita *SAMBA y correrlo tan
un Linux *server y clientes de Linux.  (O Linux *server y *Solaris
clientes, o clientes de AIX o HP-*UX o DG-*UX).  Estás corriendo *DHCP y LIGAR,
así que todavía tiene que ser capaz de trabajar.

Y sé, *BTDT, aquel *DDNS trabajos sin *SAMBA en aquella clase de *setup.
Soy seguro hay muchas personas en esta lista que es o que tiene clientes
que están corriendo *DHCP<->*DDNS<->LIGAR.

Sí, soy seguro que uno-día/algún-día *SAMBA habrá construido en
*replacements para todo este (y probablemente su propio interno *database así que puedes olvidar sobre *LDAP, olvida sobre todo sobre *Linus excepto el
*kernel...) Pero esto es ahora.

Soy seguro que *SAMBA *trata el lado de Ventanas de cosas bastante
bien, pero lo que somos la discusión está consiguiendo máquinas de Linux que trabajan con *Kerberos.
  Aquello significa conseguir adelante y entradas de DNS inverso que trabajan.
Y si estas máquinas tienen las direcciones entregadas fuera de por *DHCP que significa
tampoco "engañando" (cuando he descrito) o consiguiendo *DDNS trabajando.




> Aun así podemos mostrar que los clientes tienen una IP antes de hacer
> un ámbito *logon cuando pueden *ping el *server en *bot IP y *fqdn 
> (porque el *server es en su *etc/archivo de anfitriones. El perdiendo el vínculo parece 
> para ser lo que los clientes de ventanas tienen en vez de /*etc/anfitriones.

*Googling Veo menciona de *c:\sistema\de ventanas32\conductores\*etc\los
anfitriones

Complacen nota: Diferente el DNS, el archivo de anfitriones es bajo el control directo
del administrador del ordenador local.  Aquello es por qué tendría que ser
**writeable* sólo por raíz y usuarios de fin no tendrían que tener acceso de raíz.

Además, vuestro *nsswitch tendría que preferir DNS y sólo utilizar el archivo anfitrión
cuándo el DNS no es disponible.

Ve también *http://apoyo.*microsoft.*com/*kb/172218



>> De hecho estamos suponiendo* cosas aquí.
>>  Tú  el vertedero de las mesas de DNS?

> Cómo  yo  un vertedero?

Enviar una señal al *server, cuando describí en el exceptuar de la página
de hombre en un correo más temprano.
-- 
Si los ordenadores consiguen demasiado potentes, les podemos organizar a un comité -
que les hará dentro. -- Bradley *Bromide
-- 
A *unsubscribe, *e-correo: *opensuse+unsubscribe@xxxxxxxxxxxx
para contactar el dueño, *e-correo: *opensuse+owner@xxxxxxxxxxxx


lynn said the following on 04/01/2012 04:41 PM:

>> To correctly look up FQDN from only a IP requires treat DNS properly
>> implements reverse lookup.  We've established you don't have complete
>> and accurate reverse tables.
>>
>> Could you please elucidate.
>>
> I do not have reverse lookup. 

Then I can't see how you can expect this to work properly.

And no, spoofing Kerberos by fiddling with /etc/hosts 127.0.0.1 entry is
not "working properly".  Carlos is quite right, that is
localhost.localdomain and cannot be anything else without breaking other
fundamentals.  Changing it to the fqdn to get around the absence of
reverse lookup is subverting Kerberos.

> The forward zone is created when I start 
> bind. 

Picky: No, when you start bind it reads the config file and builds its
internal map so that it can respond to queries about the forward zone.

You need to have that zone defined and all the static devices in it
(servers, firewalls, routers) as defined resource records (RRs)

DHCP will add and remove more RRs - if you have the thing set up
properly and DHCP knows about the shared cypto key needed for secure
communications.

> It get updated when a new client (Linux or windows) boots or joins
> the domain. For ddns it has a tsig which is a Kerberos keytab. The 
> keytab was produced when the AD was first provisioned. I posted he 
> named.conf a few posts ago. I also have a static reverse zone. The only 
> thing that prevents it too from being included in the ddns is that I 
> don't know how to generate a keytab for it. This is where the Samba guys 
> have changed the bind innards.

Try reading
http://www.oceanwave.com/technical-resources/unix-admin/nsupdate.html

You recall that bind complained about a file and you created it (empty)
with 'touch'?  Well guess what....




>>>> 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)
>>
>> I think we are talking at cross [purposes or I need an update.
>> I thought SAMBA was acting as a Domain Controller and that the AD was
>> the database, possibly (but not always) implemented by LDAP.
>>
>> AD = Active Directory, a dynamically maintained database, a directory
>> service that runs on the Domain Controller and needs DNS, Kerberos and
>> LDAP to support it.
>>
>> I thought SAMBA was more than just AD.
>>
> Samba4 is a windows domain controller. It consists of a totally 
> Linux-ified AD. It has its own built in KDC and LDAP server.
> 
> Soon, it will have its own DNS server too. It already has its own 
> working DNS server but ironically it only works for forward ddns at the 
> moment.

You keep asserting that, but can you give reference please.





> 
>>
>>> Kerberos needs not only to authenticate the user but also the machines
>>> on the lan.
>> That is why *properly implemented* DNS is crucial with Kerberos.
>>
>> If the code can't do a full backward-for-ward-backward verification of
>> the IP/FQDN from the *authoritative* (and presumably secured) DNS
>> service then the fallback to the /etc/hosts is a security hole.  The
>> user in control of the client machine can put whatever he (or she) likes
>> into /etc/hosts and so spoof the identification.
>>
> Only root has access to /etc/hosts on our lan.

Picky: Its not meant to be accessed from the LAN, its meant to be
accessed from local programs, including ones that are not running as
root.  It should be 0644/root:root.

Carlos, others, would you care to verify that and explain to Lynn why
/etc/hosts needs to be readable by everyone.

Check /etc/permissions


>>>> 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?
>>
>> I don't know.  In all the systems I've worked with it boils down to the
>> DHCP server telling the DNS server.
>>
>> The address is handed out after the Linux machine is booted, long before
>> the SAMBA client comes up, so the SAMBA side of things should have
>> nothing to do with it.  All this DDNS should work regardless of the
>> presence of SAMBA, Kerberos, YP/NIS, or NFS.  SAMBA is not a requirement
>> for UNIX/Linux/AIX/HP-UX/DG-UX/Solaris-only networks and I've had it
>> running in that kind of setting.
> 
> Kerberos has to authenticate the dns server before it can do anything on 
> the lan. 

Please explain.
Are you saying that before the DNS server program listening on port 53
on the server machine can respond to DNS requests from the machine some
Kerberos authentication has to take lace?  Of what and by what?

What about the DHCP server program running on the server ... ?



> The KDC is supplied by Samba so Samba must be up before any 
> ddns takes place. 

No, that doesn't make sense.

Take all the Windows stuff off your LAN, disable SAMBA and run it just
as a Linux server and Linux clients.  (or Linux server and Solaris
clients, or AIX clients or HP-UX or DG-UX).  You're running DHCP and
BIND, so it must still be able to work.

And I know, BTDT, that DDNS works without SAMBA in that kind of setup.
I'm sure there are many people on this list who are or who have clients
that are running DHCP<->DDNS<->BIND.

Yes, I'm sure that one-day/some-day SAMBA will have built in
replacements for all this (and probably its own internal database so you
can forget about LDAP, forget about everything about Linus except the
kernel...) but this is now.

I'm sure that SAMBA *does*  deal with the Windows side of things quite
well, but what we are discussion is getting Linux machines working with
Kerberos.  That means getting forward and reverse DNS entries working.
And if these machines have addresses handed out by DHCP that means
either "cheating" (as I've described) or getting DDNS working.




> We can however show that the clients have an IP before
> doing a domain logon as they can ping the server on bot IP and fqdn 
> (because the server is in their etc/hosts file. The missing link seems 
> to be what the windows clients have instead of /etc/hosts.

Googling I see mention of
c:\windows\system32\drivers\etc\hosts

Please note: Unlike the DNS, the hosts file is under the direct control
of the local computer's administrator.  That's why it should be
*writeable* only by root and end users should not have root access.

In addition, your nsswitch should prefer DNS and only use the host file
when DNS isn't available.

See also http://support.microsoft.com/kb/172218



>> Actually we are *assuming* things here.
>> Did you do the dump of the DNS tables?

> How do I do a dump?

Send a signal to the server, as I described in the except from the man
page in an earlier mail.
-- 
If computers get too powerful, we can organize them into a committee -
that will do them in. -- Bradley's Bromide
-- 
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx


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