Lançou seu primeiro trabalho entitulado “Sentidos”, com 12 faixas que mostram versatilidade e criatividade, incluindo faixa homônima onde é possível perceber a verdadeira sonoridade da banda.

Em fase de composição de seu novo trabalho, a banda MP13 fomenta sua própria criatividade aliada ao entrosamento e ao objetivo de trazer à tona uma releitura de si mesmos, num mix de criatividade, poesia e paixão.

Sentidos, by MP13

http://sqiz.in

Uma ferramenta ótima ferramenta que conheci é o Group-Office. Esta ferramenta lhe dá total controle sobre sua rotina, desde controlando o seu calendário, até o gerenciamento de um projeto, sem falar dos e-mails e do gerenciamento de arquivos.

Para as empresas que necessitam de Mobilidade, o Group-Office possui integração total com Celulares que utilizem ActiveSync, com iPhone e Android.

O Group-Office possuí duas versões, a OpenSource que pode ser baixada gratuitamente e também a versão Professional, que oferece todos os módulos (incluindo o SyncML e o ActiveSync) e tem um custo baixo de aquisição, em relação aos concorrentes, como o Zimbra, por exemplo.

Para conhecer mais sobre o Group-Office acesse: http://www.group-office.com/

Se você gostou do Group-Office mas precisa de consultoria para instalação, entre em contato com o pessoal da Vanilla Bean e peça um orçamento. http://www.vanillabean.com.br/groupoffice/

http://marcelonunesblog.blogspot.com - Blog do meu amigo pessoal Marcelo Nunes, pintor, músico, já participou por alguns minutos do cinema nacional e hoje trabalha como tradutor.

http://contraversao.com/ - Blog do Raphael Fernandes, editor da Revista Mad. Sempre posta coisas bem interessantes sobre diversos assuntos.

http://cubo3.com.br/ - Da minha amiga Deborah Magnani. Portal com conteúdo interessantíssimo para quem gosta de cinema, música, animação, quadrinhos entre outras coisas.

Não deixem de acompanhar tanto esses blogs, quanto o meu!

Crie o arquivo /etc/ppp/peers/tim3g com a seguinte configuração:

user "tim"
connect "/usr/sbin/chat -v -V -t15 -f /etc/ppp/tim3g-chat"
/dev/ttyUSB3
115200
noipdefault
usepeerdns
defaultroute
noauth

Crie também o arquivo /etc/ppp/tim3g-chat, que é são onde os comandos AT estarão configurados no padrão de discagem do 3G da tim:

'' 'ATZ'
'OK' 'ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0'
'OK' 'AT+CGDCONT=1,"IP","tim.br"'
'OK' 'ATD*99***1#'
CONNECT ''

machine# pppd call tim3g

Pronto! Se quiser compartilhar a internet:

sysctl net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o ppp0 -s SUA_REDE -j MASQUERADE

De fato, essa fórmula sempre funcionou como esperado, mas o excesso de réplicas torna o ambiente praticamente inadministrável conforme o número de Slaves aumenta, e é óbvio que queremos que nossa aplicação seja escalável. Em um modelo deste tipo, escalar a aplicação também significa precisar de mais slaves.

A boa notícia é que o OpenLDAP possui um módulo chamado “pcache” que elimina esta necessidade absurda de milhões de réplicas dentro da sua estrutura.

O conceito é simples. Ao invés de replicar todo o diretório, o pcache armazena somente os resultados das pesquisas efetuadas e pelo tempo necessário. Uma consulta que não está em cache é respondida pelo Master (ou Slave, preferívelmente) e a que está em cache é respondida localmente.

Arquitetura com OpenLDAP Proxy Cache

A partir deste ponto, vou mostrar um exemplo de arquitetura física ignorando qualquer melhoria relacionada ao modelo utilizado dentro do diretório. Meu intuito é somente mostrar o funcionamento do “slapo-pcache”.

Exemplo simples de arquitetura :

Como é possível ver, existe a possibilidade de que a própria máquina de aplicação seja o cache. Desta forma a latência de rede já é eliminada pois a consulta é local. Digamos que é possível economizar alguns bons milisegundos (ou até segundos) para cada consulta efetuada. Obviamente, quando iniciar o serviço pela primeira vez, o seu diretório Slave vai receber uma carga maior, mas a curto prazo, essa carga deve diminuir. O Master por sua vez, será somente utilizado para gravações e algumas leituras.

A configuração do “slapo-pcache” é bastante simples, mas é necessário que você saiba exatamente todas os tipo de consultas que serão efetuadas no seu diretório. No geral, sempre sabemos quais queries serão efetuadas, salvo se seu diretório for aberto.

Instalação

A instalação é bem simples. Pode ser instalado através do gerenciador da sua distro, ou pelo conhecido trio “./configure”, “make”, “make install”.

Para o Red Hat, é necessário instalar o pacote openldap-servers-overlays e no caso de haver necessidade do compilação, são necessários os seguintes parâmetros “–backend-ldap” e “–overlay-pcache”.

Configuração

A configuração de um LDAP Cache é muito simples. A cada sessão, irei explicar qual é a função do ítem de configuração

slapd.conf

Primeiramente incluímos todos os “schemas” requeridos pelo diretório, pois caso não existirem, o OpenLDAP não consegue persistir o resultado das consultas, fazendo o cache ser ineficaz.

# Schema files
include      /etc/openldap/schema/core.schema
include      /etc/openldap/schema/corba.schema
include      /etc/openldap/schema/cosine.schema
include      /etc/openldap/schema/inetorgperson.schema
include      /etc/openldap/schema/misc.schema
include      /etc/openldap/schema/mail.schema
include      /etc/openldap/schema/nis.schema
include      /etc/openldap/schema/openldap.schema

É necessário carregar o módulo explicitamente. Em algumas distribuições é desnecessário fazer isso. Mas na dúvida, faça.

# modules
moduleload      pcache

Estes níveis de log, mostram sobre as consultas efetuadas no diretório. Para saber os outros níveis, verifique a documentação do OpenLDAP.

# log information
loglevel        stats stats2

Esta é a sessão relacionada aos backends necessários para efetuar o cache. Observe que o Backend primário utilizado aqui é o “ldap”, ou seja, a consulta feita no cache é repassada para as “uri” definidas. O “suffix” precisa ser o mesmo do seu diretório. O “rootdn” pode ser diferente.

database        ldap
suffix          "dc=mydomain,dc=com”
uri             “ldap://200.x.x.x ldap://200.x.x.y”
rootdn          "cn=manager,dc=mydomain,dc=com”

Aqui vemos a configuração do Cache. O Overlay pcache está sendo inicializado. Os valores do parâmetro proxycache são, respectivamente: tipo do backend; número de entradas no cache; número de attribute sets; número máximo de entradas; período de “consistency check”.

# slapo-pcache configuration
overlay         pcache
proxycache      bdb 100000 2 1000 100

Os “proxyAttrset”, são os attribute sets que serão retornados pelas consultas. No exemplo abaixo, minha consulta de número 0 retorna mailHost e rfc822MailAlias, enquanto minha consulta 1 retorna somente a existência de determinado attributo.
Estes “proxyAttrsets” serão utilizados pelas “proxyTemplates” a fim de consolidar o cache. Neles constam as templates das consultas que serão efetuadas, o id do attribute set e o TTL.

proxyAttrset    0 mailHost rfc822MailAlias
proxyAttrset    1 1.1
proxyTemplate   (&(uid=)(associatedDomain=)(mailHost=)) 0 3600
proxyTemplate   (&(uid=)(associatedDomain=)) 1 3600

E enfim, o tamanho total do cache (preferivelmente o mesmo do cache do overlay), o diretório onde será armazenado o cache e por último, os indexes.
Um ponto importante. Não abuse de indexes, eles são necessários, mas o excesso de índices inúteis podem gerar problemas de performance. Sempre olhe seus logs. Se faltar algum índice, constará em seus logs.

cachesize       100000
directory       /var/db/openldap-cache
index           uid,cn pres,eq
index           objectClass,associatedDomain,mailHost eq

A configuração do pcache é realmente simples. Uma vez que você sabe exatamente as queries que são feitas no seu diretório, seu cache será eficaz.
Outros tunings podem ser aplicados, mas não no slapd.conf, mas sim no DB_CONFIG no diretório de seu database.

Normalmente para um cache, costumo criar dois segmentos de memória para cache e um número maior de “lockers”, pois em ambientes de alto volume de consultas, um número baixo de “lockers” pode significar gargalo. Também deixo os transaction logs em auto-remove. Como trata-se de um cache, não existe utilidade nenhuma em preservá-los.

DB_CONFIG

set_flags DB_LOG_AUTOREMOVE
set_cachesize 0 2073741824 2
set_lk_max_locks 3000
set_lk_max_objects 1500
set_lk_max_lockers 1500

Basicamente, esta é uma configuração padrão para um cache. Como já dito, ele pode rodar diretamente e sua máquina de aplicação ou em separado mas fique atento para não confundir problemas de configuração nos “clients” com problemas de performance do cache. Um bom exemplo, é utilizar seu “base dn” diferente do que foi configurado no server. Todos os índices criados, só funcionarão corretamente se as consultas forem feitas na base correta, caso contrário, você terá problemas gigantes com deadlocks.

Espero que este artigo possa ajudar quando for arquitetar sua próxima instalação. Claro que em ambientes maiores será necessário um número maior de caches e slaves, bem como a redundância de seu Master. Em meu próximo POST sobre LDAP, mostrarei como montar um ambiente com Hot Standby. Até!

Pesquisei bastante em Ruby como o fazê-lo, mas não me senti “seduzido” pelas Libs de Ruby que construiam HTTP Servers, e também há aquela velha questão do Ruby ser mono thread. Pesquisei algo relacionado ao Perl mas infelizmente é uma linguagem que não me sinto à vontade para fazer alguma coisa, e sinceramente não gosto muito. No final, acabei escolhendo escrevê-lo em Python, pois devo confessar que existem muitas facilidades devido milhares de modulos embutidos na linguagem em sua instalação padrão.

Uma delas é o BaseHTTPServer, que constrói facilmente um servidor HTTP básico mas extermamente extensível.

O intuito deste POST é mostrar a facilidade com que se constrói um HTTPServer em Python e ainda por cima, adicionar a camada SSL por cima dele.

Escrevendo seu HTTP Server básico com SSL

user@host ~$ vim secureServer.py
 
from BaseHTTPServer import HTTPServer, BaseHTTPRequestHandler
import ssl
 
class classHandler(BaseHTTPRequestHandler): pass
 
server_addr = (127.0.0.1, 443)
httpd = HTTPServer(server_addr, classHandler)
httpd.socket = ssl.wrap_socket(httpd.socket,  \
    certfile='cert.pem', server_side=True, \
    ssl_version=ssl.PROTOCOL_SSLv23)
 
while True:
        httpd.handle_request()

Viram que simples? Mas para este pequeno protótipo funcionar corretamente, é preciso criar um certificado SSL. Como é somente teste, vou criar um “self signed”.

user@host ~$ openssl req -new -x509 -days 365 -nodes -out cert.pem -keyout cert.pem
 
Generating a 1024 bit RSA private key
..........................................................++++++
.......................++++++
writing new private key to 'cert.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:BR
State or Province Name (full name) [Some-State]:São Paulo
Locality Name (eg, city) []:SP
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Leandro LTDA
Organizational Unit Name (eg, section) []:Mail
Common Name (eg, YOUR name) []:localhost
Email Address []:leandro@localhost

Pronto, agora é só testar com o openssl client.

user@host ~$ openssl s_client -host localhost -port 443
CONNECTED(00000003)
depth=0 /C=BR/ST=S\xC3\xA3o Paulo/L=SP/O=Leandro LTDA/OU=Mail/CN=localhost/emailAddress=leandro@localhost
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=BR/ST=S\xC3\xA3o Paulo/L=SP/O=Leandro LTDA/OU=Mail/CN=localhost/emailAddress=leandro@localhost
verify return:1
---
Certificate chain
 0 s:/C=BR/ST=S\xC3\xA3o Paulo/L=SP/O=Leandro LTDA/OU=Mail/CN=localhost/emailAddress=leandro@localhost
   i:/C=BR/ST=S\xC3\xA3o Paulo/L=SP/O=Leandro LTDA/OU=Mail/CN=localhost/emailAddress=leandro@localhost
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDijCCAvOgAwIBAgIJAKY1XzcnjUW3MA0GCSqGSIb3DQEBBQUAMIGLMQswCQYD
VQQGEwJCUjETMBEGA1UECBQKU8OjbyBQYXVsbzELMAkGA1UEBxMCU1AxFTATBgNV
BAoTDExlYW5kcm8gTFREQTENMAsGA1UECxMETWFpbDESMBAGA1UEAxMJbG9jYWxo
b3N0MSAwHgYJKoZIhvcNAQkBFhFsZWFuZHJvQGxvY2FsaG9zdDAeFw0xMDAxMjEw
MTQ0MThaFw0xMTAxMjEwMTQ0MThaMIGLMQswCQYDVQQGEwJCUjETMBEGA1UECBQK
U8OjbyBQYXVsbzELMAkGA1UEBxMCU1AxFTATBgNVBAoTDExlYW5kcm8gTFREQTEN
MAsGA1UECxMETWFpbDESMBAGA1UEAxMJbG9jYWxob3N0MSAwHgYJKoZIhvcNAQkB
FhFsZWFuZHJvQGxvY2FsaG9zdDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
yCX09Doe3bfFwrmGjAA3cDOUC47vuOVUkWzlnkX2e7nWN7J13amFHtBFXG2YunEs
wPEm5VZMMtjq5fhmKdcw+y6U2Lf6iS1Q5vEutuY/L2XbHlzctMFbasqkuVO8H0oB
Lqg9zTuRfx/BJ7BmhrWZMKYMYbP/PbFGejMrhMUzcp0CAwEAAaOB8zCB8DAdBgNV
HQ4EFgQU6s23dwSaSIO2CRXnzSqRCfbJLyQwgcAGA1UdIwSBuDCBtYAU6s23dwSa
SIO2CRXnzSqRCfbJLyShgZGkgY4wgYsxCzAJBgNVBAYTAkJSMRMwEQYDVQQIFApT
w6NvIFBhdWxvMQswCQYDVQQHEwJTUDEVMBMGA1UEChMMTGVhbmRybyBMVERBMQ0w
CwYDVQQLEwRNYWlsMRIwEAYDVQQDEwlsb2NhbGhvc3QxIDAeBgkqhkiG9w0BCQEW
EWxlYW5kcm9AbG9jYWxob3N0ggkApjVfNyeNRbcwDAYDVR0TBAUwAwEB/zANBgkq
hkiG9w0BAQUFAAOBgQCl6+gzbq4gQfE/W5NYCX1S/bsNFaGaDoSr8nzibF++3NeI
CjgtDciimmSb330AJE1GSC9xqvLF86LV2wvIw3W6eR7+YYgGfoPv2eOnGO/djsKM
/0MvPoUjJPfP9k2RftyYQMaKPMXGtGGCWnlm6bUade9wq4BdBYkKRp42Rb83qQ==
-----END CERTIFICATE-----
subject=/C=BR/ST=S\xC3\xA3o Paulo/L=SP/O=Leandro LTDA/OU=Mail/CN=localhost/emailAddress=leandro@localhost
issuer=/C=BR/ST=S\xC3\xA3o Paulo/L=SP/O=Leandro LTDA/OU=Mail/CN=localhost/emailAddress=leandro@localhost
---
No client certificate CA names sent
---
SSL handshake has read 1072 bytes and written 316 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA
    Session-ID: 0DF03B0D70244E8A4E357504AEB010FCCBF02977E1B530FC8E2F47057AB5D949
    Session-ID-ctx:
    Master-Key: 5E124A87C6BAE38AFF3CA2F78EBDB9A989E988B005AB596D7FCF7D93B48D7FD1C4F1FCAEA325DC48137D0EBC23DDBB4A
    Key-Arg   : None
    Start Time: 1264038343
    Timeout   : 300 (sec)
    Verify return code: 18 (self signed certificate)
---

Pronto, seu HTTPServer com SSL está funcionando. Obviamente, nenhum dos métodos está sendo implementado, mas isto é facilmente de se fazer. O BaseHTTPServer, por padrão não implementa nenhum método, sendo assim, para facilitar você pode extender o SimpleHTTPServer que já implementa os métodos do_GET e do_HEAD, a única coisa que é necessário fazer é implementar os outros método desejado, como do_POST, do_PUT, do_DELETE, etc. Verifique a documentação!

É isso aí galera!!

Referencias

http://docs.python.org/library/ssl.html
http://docs.python.org/library/basehttpserver.html ]]> http://www.wish4web.com.br/blog/theflockers/2010/05/04/escrevendo-um-servidor-https-em-python/feed/ http://www.wish4web.com.br/blog/theflockers/2009/11/15/replicacao-multi-master-no-openldap-24/ http://www.wish4web.com.br/blog/theflockers/2009/11/15/replicacao-multi-master-no-openldap-24/#comments Mon, 16 Nov 2009 02:47:43 +0000 admin http://www.wish4web.com.br/blog/theflockers/?p=113 As versões mais antigas, era possível efetuar a replicação somente via slurpd e na configuração Master para N Slaves. Com o lançamento da versão 2.4, o OpenLDAP passou a proporcionar diversas formas de replicação, como Mirror Mode, N-Way Multimaster e ainda Master-Slave.

Este pequeno tutorial, explica de forma rápida a configuração para Alta-disponibilidade (N-Way Multimaster) para OpenLDAP 2.4, que sempre foi uma das principais solicitações da comunidade.

Configurando do Slapd

Fazer o setup manual do slapd.conf, ex:

# schemas
include "/usr/loca/etc/openldap/schema/core.schema"
include "/usr/loca/etc/openldap/schema/corba.schema"
include "/usr/loca/etc/openldap/schema/cosine.schema"
include "/usr/loca/etc/openldap/schema/inetorgperson.schema"
include "/usr/loca/etc/openldap/schema/misc.schema"
include "/usr/loca/etc/openldap/schema/nis.schema"
include "/usr/loca/etc/openldap/schema/openldap.schema"
 
moduleload back_bdb
 
database bdb
suffix   "ou=Mail, o=Teste"
rootdn   "cn=root, ou=Mail, o=Teste"
rootpw
directory /var/db/openldap-data
 
# Indexes
index objectClass eq
index cn,uid,associatedDomain eq

Feita a configuração básica, é necessário converter o arquivo de configuração para o novo “estilo” de configuração para o OpenLDAP 2.4. Isto pode ser feito com o commando slaptest.

root# mkdir /usr/local/etc/openldap/slapd.d/
root# slaptest -f /usr/local/etc/openldap/slapd.conf -F /usr/local/etc/openldap/slapd.d/

Serão gerados os arquivos de configuração da versão 2.4 do OpenLDAP.

É necessário também alterar os seguintes arquivos adicionando os seguintes atributos (em todos os nós):

Em /usr/local/etc/openldap/slapd.d/cn=config.ldif:

# alterar o número para cada nó
olcServerID: 1

e

Em /usr/local/etc/openldap/slapd.d/cn=config/olcDatabase={0}config.ldif:

olcRootPW: <senha>

A partir daí, o serviço deve ser iniciado.

Configurando a replicação

Com o novo tipo de configuração, tudo deve ser feito via arquivos LDIF e alterados na database cn=config do OpenLDAP, via ldapmodify.

Crie o um arquivo setup.ldif com o seguinte conteúdo:

dn: cn=config
changetype: modify
replace: olcServerID
olcServerID: 1 ldap://<server1>
olcServerID: 2 ldap://<server2>
dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
 
dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcSyncRepl
olcSyncRepl: rid=001 provider=ldap://<server1> binddn="cn=config" bindmethod=simple
credentials=secret searchbase="cn=config" type=refreshAndPersist
retry="5 5 300 5" timeout=1
olcSyncRepl: rid=002 provider=ldap://<server2> binddn="cn=config" bindmethod=simple
credentials=secret searchbase="cn=config" type=refreshAndPersist
retry="5 5 300 5" timeout=1
-
add: olcMirrorMode
olcMirrorMode: TRUE

Adicionar ao diretório

root# ldapmodify -x -D"cn=config" -w  -f setup.ldif

Isto fará a replicação da database “cn=config”. Fazer o mesmo processo no LDAP SLAVE.
Replicando a base de dados “ou=Mail,o=Teste”.

A base de dados cn=config, é importante pois desta forma, todos os nós serão configurados automaticamente, quando for feito o setup para a replicação da base “ou=Mail,o=Teste”, que possui os dados importantes.

Criar um arquivos data.ldif:

dn: olcDatabase={1}bdb,cn=config
changetype: modify
add: olcMirrorMode:
olcMirrorMode: TURE
add: olcLimits
olcLimits: dn.exact="cn=root,ou=Mail,o=Teste" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
#replica 1
add: olcSyncRepl
olcSyncRepl: rid=003 provider=ldap://<server1> binddn="cn=root,ou=Mail,o=Teste"
bindmethod=sinple credentials=secret searchbase="ou=Mail,o=Teste"
type=refreshOnly interval=00:00:00:10 retry="5 5 300 5" timeout=1
#replica 2
add: olcSyncRepl
olcSyncRepl: rid=004 provider=ldap://<server2> binddn="cn=root,ou=Mail,o=Teste"
bindmethod=sinple credentials=secret searchbase="ou=Mail,o=Teste"
type=refreshOnly interval=00:00:00:10 retry="5 5 300 5" timeout=1
 
# Habilita o syncprov
dn: olcOverlay=syncprov, olcDatabase={1}bdb,cn=config
changetype: add
objectClass: olcOverLayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov

Feito isso, adicionar os dados no Diretório:

root# ldapmodify -x -D"cn=config" -w  -f data.ldif

Pronto! Está funcionando!

Parece óbvio, mas poucos se lembram da possibilidade, de “cachear” as conexões IMAP em uma única, a fim de diminuir as requisições IMAP vindas por HTTP (webmails, em específico), pois como o HTTP é um protocolo “stateless”, ou seja, não mantém uma conexão persistente e automaticamente cada REQUEST é uma nova conexão IMAP em seu servidor.

Para resolver isto, existe a solução de Proxy IMAP. Existem alguns software para isto, mas no momento estou usando o “imapproxy” que pode ser baixado no site do projeto, www.imapproxy.org.

O software é extremamente simples e intuitivo, não precisando de mais de 10 minutos pra entender e colocar no ar.

A característica principal do software é manter uma conexão única por usuário. Ele mantém as credenciais enviadas pelo client cacheadas e uma conexão persistente com o servidor IMAP.

Instalação

Baixe o software no site do projeto:

1

user ~/ $ wget http://www.imapproxy.org/downloads/up-imapproxy-1.2.6.tar.gz

O imapproxy depende de ncurses para compilar, então, baixe-o e instale-o!

Compile-o e instale-o, ou então busque o pacote da sua distro.

Para os Slackers de plantão:

1
2
3
4
5

user :~$ tar xvzf up-imapproxy-1.2.6.tar.gz
user :~$ cd up-imapproxy-1.2.6/
user :~/up-imapproxy-1.2.6$ ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
user :~/up-imapproxy-1.2.6$ make
user :~/up-imapproxy-1.2.6$ sudo make install

Instalado, a configuração é extremamente simples, mas vou explicar algumas delas.
O arquivo de configuração de acordo com nossa instalação estará em /etc/imapproxy.conf.

1
2
3
4
5
6
7

server_hostname 200.x.x.x  # Este será o servidor de destino
cache_size 100 # Número de conexões máximas que poderão ser "proxyadas"
listen_port 143 # Onde o imapproxy escutará as conexões
# listen_address 127.0.0.1 # Neste caso se indefinido (comentado), irá escutar todas os endereços.
server_port 1143 # Porta do servidor de destino, neste caso, estou usando o IMAP em uma porta diferente.
cache_expiration_time 300 # Tempo do cache em segundos
proc_username mail # Usuário que irá rodar o processo do imapproxy

Para configuração básica (provavelmente a maioria dos casos), estes parâmetros serão os utilizados, mas existem alguns poucos a mais que poderão ser alterados de acordo com a necessidade.

Para iniciar o serviço é somente executar o daemon:

1

user ~$ sudo imapproxy

Pronto, seu IMAP Proxy está no ar!