Otra de las grandes cosas de Twisted es que tiene varias opciones de RPC. De éstas, la que me parece más pythonesca es la que dieron en llamar Perspective Broker. Con esta parte del framework sólo tenemos que heredar de un par de clases, usar un par de factories ya listas para usar, y ponerle remote_ a los métodos que queremos exportar:

from twisted.spread import pb
from twisted.internet import reactor, defer

class MyServer (pb.Root):
    # ...
    def remote_hello (self, greeting):
        print "client says %s" % greeting
        return "why, hello there!"

s= MyServer ()
reactor.listenTCP (port, pb.PBServerFactory (s))
reactor.run ()

Éste es un server que exporta un método remoto hello. El cliente no es mucho más difícil:

def answered (answer):
    print "server said %s" % answer

def connected (root):
    root.callRemote ('hello', 'hi server!').addCallback (answered)

factory= pb.PBClientFactory ()
reactor.connectTCP (name, port, factory)
factory.getRootObject ().addCallback (connected)

Lo primero que tenemos que pedir antes de poder hacer nada es el "objeto raíz". Éste es el objeto que nos va a permitir acceder a todos los servicios remotos ofrecidos por el server. Este objecto es el s que creamos en el server y que pasamos como objeto raíz a la pb.PBServerFactory. getRootObject() nos devuelve un Deferred.

Una vez obtenido el objeto raíz, podemos empezar a llamarle métodos remotos. Notar que callRemote() recibe el nombre del método remoto como un string, y el resto de los parámetros que pasamos son los parámetros con los que va a ser llamado el método remoto en el server. Como es de esperarse, una llamada a un método remoto no vuelve inmediatamente, sino que nos da también un Deferred.

Ahora bien, vemos que los Deferreds son la estrella del framework, y que los usamos en todos lados... ¿Qué pasa cuando un método remoto no puede devolver inmediatamente el resultado? Pues, aunque parezca raro y obvio al mismo tiempo, ¡devuelve un Deferred!:

    # ... en MyServer
    def bye (self):
        return defer.succeed (True)

Acá estoy usando defer.suceed(), que es una función que devuelve un Deferred con su valor ya disponible. Esto es útil para cuando en algunos casos podemos calcular el valor de la respuesta ya, pero en otros casos los tenemos que ir a buscar en otro lado. También existe defer.fail().

Ahora bien, acá entra un poco la magia de Twisted. Es obvio que este Deferred no es el que es devuelto por callRemote(), porque ése es el de haber llamado a un método remoto, no el que devuelve ese método por no tener la respuesta inmediatamente. Lo que no es tan obvio es que este Deferred nunca viaja por la red. Perspective Broker se da cuenta de que el valor no está disponible aún y por lo tanto no retorna nada por la red. Esto es posible porque del otro lado ya hay un Deferred "esperando". Cuando el resultado esté disponible en el server, podemos llamar al método callback() de la promesa con el valor calculado y recién entonces se manda un mensaje por la red y se resuelve la promesa del lado del cliente:

    # ... MyServer
    mxCalc= relaymanager.MXCalculator ()

    def remote_resolveMX (self, hostname):
        promise= defer.Deferred ()
        mxCalc.getMX (hostname).addCalback (self.resolvedMX, promise)
        return promise

    def resolvedMX (self, mxRecord, promise):
        if mxRecord is not None:
            answer= mwRecord.name
        else:
            answer= None
        promise.callback (answer)

Acá estoy usando otro detalle que creo que no había presentado antes: estoy llamando a addCallback() no sólo con un callback, sino que le agrego otro parámetro, una referencia a la promesa que devolví. Cuando getMX() resuelve su valor, el callback es llamado con ese resultado como primer parámetro y los otros parámetros que pasé a addCallback() después. Esto me permite juntar el resiltado con la promesa devuelta anteriormente.

Hay varias cosas más en el PB. Hay objetos que se pueden referenciar remotamente, que se pueden copiar (hay dos tipos, pero aún no les agarro la mano) y un par de cosas más. Además, Twisted permite RPC usando XML-RPC (buzzword!) y también acceso a/servido de webservices (buzzword!) a través de SOAP y REST (buzzword, buzzword!).

Vamos viendo que Twisted tiene muchas cosas pensadas, y que los conceptos que maneja no son muchos ni muy complicados. Si puedo decir que en la forma en que se van 'partiendo' las soluciones en métodos (estados) no ayuda a la legibilidad posterior del código. Por ejemplo, vean cómo empezamos a tener métodos que representan estados y que son varios para algo que de otra forma nos parecería más sencillo:

    # ... MyServer
    def remote_resolveMX (self, hostname):
        return mxCalc.getMX (hostname)
    # ...

# ... cliente
root= factory.getRootObject ()
mx= root.callRemote ('resolveMX', 'decode.com.ar')
# mandar un mail a pyar...

Tengo algunas ideas de cómo simplificar estas cosas. Básicamente se basa en partir el conjunto de máquinas de estados representado en una sola clase a una clase maestra que coordina todo y varias clasesitas que manipulan las distintas maquinitas de estados. Después les cuento bien.

twisted python

Desde hace como dos semanas que vengo esporádicamente peleando con un problema: Tenía que poner a andar el plugin de Mercurial para Trac. Según las instrucciones de la página, sólo es cuestión de generar un .egg (¿se acuerdan?), ponerlo en el directorio plugins del environment y ya. Pero corriendo tracd y entrando con un browser me daba:

TracError: Unsupported version control system "hg"

Mi primer sospechoso era el .egg; creía que no lo estaba encontrando. Prendiendo el logging en el trac.ini descubrí que en realidad si lo levantaba. Siguiendo un par de links encontré una sugerencia de correr todos los imports que corre el backend.py del plugin. Finalmente descubrí que la línea:

from mercurial.revlog import LookupError

fallaba. Se vé que el Mercurial que viene en Etch (0.9.1-1+etch1) no es del todo compatible, a pesar que la página del plugin dice que lo es, inclusive hasta con 0.8. Para "repararlo" simplemente saué las (1) referencias a LookupError.

trac mercurial sysadmin

Hoy vamos a ver cómo hacer entrega remota de un mail. Como somos un server que recibió un mail que tiene que ser entregado en otro, hay una serie de pasos que tenemos que hacer. Empecemos con una implementación de t.m.s.IMessage que manda a un smarthost:

class Relay (object):
implements (smtp.IMessage)

    def __init__ (self, router, user):
    # select smarthost based on src domain
    self.user= user
    self.smarthost= 'our.smarthost.com'
    self.lines= []
    self.eom= False
    self.router= router

def lineReceived (self, line):
    self.lines.append (line)

def eomReceived (self):
    return self.send ()

def send (self, mxRecord=None):
    sender= smtp.sendmail (self.smarthost, self.user.orig,
    [self.user.dest], '\n'.join (self.lines), '')
    sender.addCallback (self.sendComplete)
    return sender

def sendComplete (self, *data):
    del self.lines
    return data

def connectionLost (self):
    del self.lines

Una cosa que no expliqué en el post anterior es el valor devuelto por eomReceived(). En ese caso era return self.mailbox.appendMessage (messageData); en éste, después de un par de vueltas, es el resultado de smtp.sendmail(). Lo que estamos devolviendo es un Deferred.

Los Deferreds son una parte importante de Twisted. Son básicamente una promesa de que en algún momento va a haber un valor disponible para devolver, pero que mientras le vamos dadndo esto como para que tenga. El truco es luego conectar con esa promesa nuestros callbacks llamando a addCallback(). Esos callbacks van a ser llamados cuando el valor esté disponible. También se pueden agregar errbacks, que son callbacks que son llamados cuando la operación que pedimos tuvo un error (típicamente una excepción).

Eso es exactamente lo que estamos haciendo en send(). t.m.s.sendmail() nos devuelve un Deferred al que le conectamos nuestro sendComplete() y lo devolvemos. sendComplete() simplemente borra las líneas (aparentemente tarde, ya veremos que nos van a hacer falta) y continúa la cadena de callbacks del deferred; cadena que se va armando de esta forma: cuando se llama a callback() en un deferred, éste llama al primer callback. El resultado de este callback es pasado al siguiente, y así.

Esto así como está manda por un smarthost. La diferencia entre mandar todo por un smarthost y mandar directamente es que esta última requiere un paso extra: averiguar a qué máquina debe entregarse el mail. Me refiero al registro MX. Vamos a tener que hacer una consulta de DNS mientras recibimos el mail. Una vez que tengamos ambos vamos a poder hacer la entrega, y finalizar. Veamos cómo nos las arreglamos:

mxCalc= relaymanager.MXCalculator ()

class Relay (object):
implements (smtp.IMessage)

def __init__ (self, router, user):
    # deliver by ourselves
    self.smarthost= None
    resolver= self.getSMTPServer (user)
    resolver.addCallback (self.send).addErrback (self.queue)
    self.lines= []
    self.eom= False
    self.router= router

def getSMTPServer (self, user):
    return mxCalc.getMX (user.dest.domain)

def lineReceived (self, line):
    self.lines.append (line)

def eomReceived (self):
    self.eom= True
    if self.smarthost is None:
        print "WARN: mail received and no smarthost!"
    else:
        print "mail finished; sending..."
        self.send ()
    self.sentSignal= defer.Deferred ()
    return self.sentSignal

def send (self, mxRecord=None):
    if mxRecord is not None:
        # mxRecord is a dns.*Record instance
        # mxRecord.name is a dns.Name instance
        self.smarthost= mxRecord.name.name
    if self.eom:
        sender= smtp.sendmail (self.smarthost, self.user.orig,
            [self.user.dest], '\n'.join (self.lines), config.heloAs)
        sender.addCallback (self.sendComplete).addErrback (self.queue)

def queue (self, error):
    self.router.queue (error=error, user=self.user, mail=self.lines)
    self.sentSignal.callback (True)

def sendComplete (self, *data):
    del self.lines
    print ignore
    self.sentSignal.callback (True)

def connectionLost (self):
    print "WARN: unfinished mail!"
    del self.lines
    self.sentSignal.errback (False)

Acá hay varias cosas. Por un lado tenemos una función que se encarga de pedir el registro MX, la que devuelve un Deferred al que le enganchamos nuestra función de entrega. Al mismo tiempo vamos recibiendo el mail, y cuando termine también intenta hacer la entrega. Ahora, acá el truco es crear un Deferred y devolverlo inmediatamente en eomReceived(). Cuando el mail es enviado finalmente, nuestro callback sendComplete() es llamado, el que a su vez hace un callback de nuestro Deferred. Por último, si tenemos un error de entrega, enconlamos a través de nuestro router el mail para un posterior intento de entrega.

Lo que vimos en este post es el manejo de Deferreds, y cómo se los usa para prometer volver a llamar cuando el resultado está disponible. Hasta ahora es el único momento en el que realmente he necesitado manejarlos. Supongo que ya volveré a verlos cuando empieze el duro camino de implementar filtros.

twismtpy python twisted

En la oficina tenemos un server que entrega nfs; también tenemos mucha gente que compila cosas. Estos dos parámetros hacen que tener sincronizadas las horas de las máquinas sea una necesidad. Pra esto se pueden usar los paquetes ntpdate (para on-time-sync) y ntp (para keep-in-sync). Hoy estuve revisando bien como interactúan ambos, sobre todo al momento del booteo. antes una descripción de qué hace cada uno.

ntp se encarga de mantener la hora de la máquina mas-o-menos sincronizada con la de una fuente externa. Si llega a haber cierta diferencia, se encarga de ir acomodando la hora de a poco, para que el sistema no sufra por cambios bruscos. Un problema que tiene es que si la diferencia con la referencia externa es muy grande, ntp no es capaz de salvar las diferencias y entonces ''no hace nada''. ntpdate se encarga simplemente de setear incondicionalmente la hora local según la hora que consiga de esta referencia externa. El escenario ideal sólo haría uso de ntp, pero en general se podría usar también ntpdate para máquinas con el reloj para-el-carajo, como parece ser el caso de al menos una de nuestra máquinas.

El tema es que, por defecto, ntpdate utiliza un archivo de configuración de ntp, pero a su vez corre despúes de éste, en cuya condición falla pues el puerto UDP que usa ya está en uso por ntp. Desinstalando ntp nos deja sin el archivo de configuración, y en realidad tiene sentido quedarnos con él.

La solución que encontré es simplemente hacer un symlink al script de ntpdate en /etc/network/if-up.d a un nombre anterior al de ntp (por ejemplo, mntpdate). Voy a ver si en debian/ubuntu me dan pelota con lo de ponerles mejor orden que simplemente el nombre.

sysadmin ubuntu debian

This wiki has attachments disabled.

If attachments are enabled, the wiki admin can control what types of attachments will be accepted, via the allowed_attachments configuration setting.

For example, to limit arbitrary files to 50 kilobytes, but allow larger mp3 files to be uploaded by joey into a specific directory, and check all attachments for viruses, something like this could be used:

virusfree() and ((user(joey) and podcast/*.mp3 and mimetype(audio/mpeg) and maxsize(15mb)) or (!ispage() and maxsize(50kb)))

The regular PageSpec syntax is expanded with the following additional tests:

• "maxsize(size)" - tests whether the attachment is no larger than the specified size. The size defaults to being in bytes, but "kb", "mb", "gb" etc can be used to specify the units.

• "minsize(size)" - tests whether the attachment is no smaller than the specified size.

• "ispage()" - tests whether the attachment will be treated by ikiwiki as a wiki page. (Ie, if it has an extension of ".mdwn", or of any other enabled page format).

  So, if you don't want to allow wiki pages to be uploaded as attachments, use !ispage() ; if you only want to allow wiki pages to be uploaded as attachments, use ispage().

• "mimetype(foo/bar)" - checks the MIME type of the attachment. You can include a glob in the type, for example mimetype(image/*).

• "virusfree()" - checks the attachment with an antiviral program.

Vamos a empezar con un server básico, que es con lo que empecé yo. El código es prácticamente lo mismo que está en el libro que mencioné. Básicamnete es un servidor que sabe recibir mails y guardarlo en maildirs:

from twisted.mail import smtp, maildir
from twisted.internet import protocol, reactor

from zope.interface import implements
import os
from email.Header import Header

class MailDir (object):
    """
    handles the local delivery to a maildir inbox
    """
    implements (smtp.IMessage)

    def __init__ (self, user):
        userDir= str (user.dest.local)
        # we create a directory for this user
        if not os.path.exists (userDir):
            os.mkdir (userDir)

        inboxDir= os.path.join (userDir, 'Inbox')
        self.mailbox= maildir.MaildirMailbox (inboxDir)
        self.lines= []

    def lineReceived (self, line):
        self.lines.append (line)

    def eomReceived (self):
        # message is complete, store it
        self.lines.append ('')
        messageData= '\n'.join (self.lines)
        return self.mailbox.appendMessage (messageData)

    def connectionLost (self):
        # unexpected loss of connectio, don't save
        del (self.lines)

class MailRouter (object):
    implements (smtp.IMessageDelivery)

    def __init__ (self, validDomains):
        self.validDomains= validDomains

    def receivedHeader (self, helo, origin, recipients):
        # client is how the client ident'ed itself
        # clientIP is the ip of the client side's end
        # we could do a reverse DNS lookup and check if it's true
        # also check on RBL's and such
        client, clientIP= helo
        recipient= recipients[0]
    # this must be our CNAME
        myself= 'localhost'
        value= """from %s [%s] by %s with ESMTP for %s; %s""" % (
            client, clientIP, myself, recipient, smtp.rfc822date ()
            )
        return "Received: %s" % Header (value)

    def validateFrom (self, helo, originAddress):
        self.client= helo
        # originAddress is a twisted.mail.smtp.Address
        # if the from is invalid, we should
        # raise smtp.SMTPBadSender
        return originAddress

    def validateTo (self, user):
        """
        routing is the most complicated part of serving an smtp server

        we can be run on a laptop that only wants to send mail
        with possibly many source address

        we can be run on a server that has a local user database;
        it con be a smarthost for otehr machines
        it can be a satellite machine with only a smarthost
        """
        if user.dest.domain in self.validDomains:
            return lambda: Maildir (user)
        else:
            raise smtp.SMTPBadRcpt (user)

class SMTPFactory (protocol.ServerFactory):
    def __init__ (self, validDomains):
        self.validDomains= validDomains

    def buildProtocol (self, addr):
        delivery= MailRouter (self.validDomains)
        smtpProtocol= smtp.SMTP (delivery)
        smtpProtocol.factory= self
        return smtpProtocol

if __name__=='__main__':
    import sys

    # normal local server
    domains= sys.argv[1].split (',')
    reactor.listenTCP (2525, SMTPFactory (domains))
    reactor.run ()

Tenemos tres clases. La primera es SMTPFactory, la cual es sólo un factory de protocols. Tiene un método, buildProtocol() que tiene que construir un protocolo y devolverlo.

La segunda que veremos es la MailDir. Ésta implementa la interfaz t.m.s.IMessage, que se usa para la entrega de un mensaje. En este caso es una entrega local a un maildir, aunque luego implementaremos la entrega remota con esta misma interfaz. La clase tiene que implementar tres métodos:

lineReceived() es llamado por cada nueva línea del mail que llega. No hace diferencias entre si es parte del cuerpo o del header. Si tuviéramos que hacer algún procesamiento, como toquetear headers o rechazar el mail por tamaño, lo deberíamos hacer en este nivel.

eomReceived() se llama cuando todo el mail ha sido ya entregado a través de lineReceived(). En este caso escribimos el mail finalmente en un maildir. Fíjense que como t.m.maildir.MaildirMailbox no tiene esta misma interfaz, tenemos que acumular la líneas en una lista y pegarlas todas y dársela de commer a t.m.md.MDMB.append(). Ya me sentaré a verificar si no hay una mejor API para esto.

Finalmente, connectionLost() se llama si la conexión se pirde antes de recibir todo el mail.

Hasta ahora todo sencillo, sólo un factory y la implementación de una entrega local sin muchas luces (no sabe buscar el maildir de un usuario, sino que asume un directorio propio). Gran parte del meollo del mail está en la tercera clase que veremos, MailRouter.

La MailRouter es la que sencargará de definir si el mail es entregable o no. En nuestro caso inicial, no la picadura que me estoy rascando, vamos a permitir relaying libre siempre y sólo localmente a través de la clase MailDir. Antes de ver lo métodos implementados, veamos una conversación típica en SMTP:

>>> 220 mustang.grulicueva.net NO UCE NO UBE NO RELAY PROBES
<<< helo gurrumin
>>> 250 mustang.grulicueva.net Hello 127.0.0.1, nice to meet you
<<< mail from: mdione@except.com.ar
>>> 250 Sender address accepted
<<< rcpt to: mdione@localhost
>>> 250 Recipient address accepted
<<< rcpt to: root@localhost
>>> 250 Recipient address accepted
<<< data
>>> 354 Continue
<<< Subject: bongs
<<< To: mdione@whitehouse.gov
<<< 
<<< 
<<<         This is top secret info. So secret we won't even tell you. Sorry.
<<< .
>>> 250 Delivery in progress
<<< quit
>>> 221 See you later

Tenemos marcados con >>> lo que escupe el server y con <<< lo que manda el cliente. Básicamente el protocolo se basa en tres fases: presentación, declaración de entrefa y cuerpo. En la presentación el cliente se identifica con un nombre. Acá también puede autenticarse con un par (usuario, passwd), arrancar encripción y todo ese tipo de cosas relativas a la conexión en si. Luego dice de quién viene y a quiénes va el mail, y finalmente el mail en sí. Notar que en esta parte van también los headers (estamos viendo solo dos, un To y un Subject. Estas dos últimas estapas se pueden repetir una detrás de la otra las veces que se quiera.

La clase Mailrouter implementa la interfaz t.m.s.IMessageDelivery, se crea una por cada conexión al puerto en el que estamos escuchando, en la que tenemos que implementar otros tres métodos:

El primero es el validateFrom(), el que es llamado por cada mail from. Recibe como parametro una tupla de str. El primer str es el nombre que usó el cliente en el comando helo y el segundo es el IP real. También recibe un t.m.s.Address con el from. Como dicen los comentarios, acá podríamos fijarnos si el nombre y el ip coinciden, o si está en un RBL o cosas parecidas, o si damos relay para el from. En este caso aceptamos todo. Notar que lo devuelto es también un t.m.s.Address. Eventualmente se podría devolver otro, aunque no se me ocurre en qué casos.

El más importante, el validateTo(). ¿Porqué digo el más importante? Porque éste es el que se encarga de hacer la decisión de ruteo, es decir, de decidir qué implementación de t.m.s.IMessage se va a encargar del delivery basado tanto en el from como en el to del mail. El parámetro que nos pasan es un t.m.s.User, el cual contiene ambas direciones en sus atributos orig y dest respectivamente. En este caso sólo nos fijamos que el destino esté entre los dominos al que le hacemos relay local, y si no levantamos una t.m.s.SMTPBadRcpt, la que se traduce en un mensaje de no relay al cleinte. Notar que lo que devuelve no es ni una instancia ni siquiera la clase que va a implementar el delivery, sino una función que devuelve una instancia. En el próximo post voy a estar mostrando porqué, y en los subsiguientes posts voy a complicar este método para lograr las políticas de relaying que tengo planeado.

Finalmente, receiveHeader() es el más sencillo. Sólo tenemos que devolver un string con un header Received apropiado para este delivery. Es éste nos pasan la misma tupla con dos str que en validateFrom(), la dirección de origen y la lista de instancias de t.m.s.User con los recipientes. Ejemplos de estos headers lo podemos encontrar en cualquier mail:

Received:  from [192.168.1.77] (unknown [201.250.21.186])
        (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
        (No client certificate requested)
        by mail.madap.com.ar (Postfix) with ESMTPSA id 978604613
        for <mdione@grulic.org.ar>; Mon, 30 Jun 2008 08:16:56 -0300 (ART)
Received:  by 10.141.105.17 with HTTP; Wed, 2 Jul 2008 13:55:38 -0700 (PDT)
Received:  from localhost ([127.0.0.1] helo=forster.canonical.com)
        by forster.canonical.com with esmtp (Exim 4.69 #1 (Debian))
        id 1KDHgi-0000eo-Fa
        for <mdione@grulic.org.ar>; Mon, 30 Jun 2008 12:36:52 +0100

Bueno, es todo por hoy. Tengan en cuenta que todavía no pretendo que éste sea un tutorial de Twisted, pero si va mostrando cosas que nos vamos a encontrar en muchas de las implementaciones de servicios con este framework.

twismtpy python twisted

Bueno, hoy estoy verbose. Se vé que estoy haciendo cosas de nuevo...

La cuestión es que, como dije un par de posts atrás, ando con la idea de hacer un servidor de mail no configurable, sino programable. Es decir, que en vez de andar toqueteando archivos de configuración, tratando de adivinar la semántica de cada opción a partir de los manuales, uno se sienta y lo programa de la forma en que uno quiera que se comporte. Esta idea surgió en una charla con otro sysadmin amigo hará unos 3 o 4 años, y quedó dormida hasta que con Lucio vimos la charla de Lighttpd en San Francisco.

Es obvio que un proyecto de este estilo no funcionaría bien a menos que la programación sea relativamente sencilla. Y no puede ser sencilla si el lenguaje no es sencillo. Y qué mejor que python para esa tarea. Y si hablamos de python, de servidores y apuntamos un poco alto, no podemos dejar a twisted fuera de la ecuación.

Ahora, si hay algo en twisted es su curva de aprendizaje no intuitiva. Twisted es un framework para desarrollo de servidores con un sistema de eventos asíncronos. Con esto se saca un montón de problemas de escalabilidad asociados a servidores con múltiples clientes. El tema es que entonces, se tiene que programar el sistema como una máquina de estados, que en general es así, pero donde cada estado es prácticamente un procedimiento aparte y además no se puede quedar haciendo nada pesado. Esto último es porque twisted es un event loop, y si en uno de los eventos nos quedamos haciendo cosas sin devolver el control al loop, el loop no puede procesar otros eventos.

Mas allá de todo eso, me decidí a usarlo lo mismo. twisted.mail tiene un montón de cosas listas para usar, sobre todo muchas interfaces, pero la documentación es inicialmente un poco confusa y no hay un tutorial que uno pueda seguir. Por suerte en la oficina tenemos un "programming with Twisted" que justo viene con ejemplos de un server de SMTP y de un cliente, inclusive explicados.

Comenzando con ése es que me largué a hacer esto. Como la idea es que sea programable, y con esto lograr la mayor flexibilidad de configuración, decidí empezar por rascarme donde me pica: me hace falta un server que sepa usar varios samarthosts, dependiendo de a qué red esté conectado y de qué cuenta de mail use para enviar mail, y que soporte encolado cuando no tenga conexión a la red.

En sucesivos posts voy a ir poniendo cachos de código mas o menos explicando como funciona todo.

python twisted twismtpy

Hoy llegué a la oficina con la idea de que algunos tracs aún no andaban. Resultó que la auth contra LDAP no estaba lista. Encontré que esta configuración si andaba:

    AuthLDAPURL ldap://ldap.except.com.ar/ou=People,dc=except,dc=com,dc=ar
    Require valid-user

Mientras que esta otra no:

    AuthLDAPURL ldap://ldap.except.com.ar/ou=People,dc=except,dc=com,dc=ar
    AuthLDAPGroupAttribute memberUid
    AuthLDAPGroupAttributeIsDN off
    Require group cn=except,ou=Group,dc=except,dc=com,dc=ar

Resulta que ahora tenés que avisarle que el grupo lo tiene que buscar en el LDAP:

    Require ldap-group cn=except,ou=Group,dc=except,dc=com,dc=ar

sysadmin apache ldap