td - uma ferramenta simples, completa e útil

Há algum tempo já que quando bate a vontade de ser organizado eu abro o vim e crio uma lista dos itens que tenho para executar. Logo que os concluo edito novamente o arquivo e coloca a data de conclusão. Afim de ter um controle de quanto tempo a tarefa já estava na lista.

Hoje navegando nesse mar sem fim da internet, encontrei uma ferramenta escrita em python que implementa um TODO List. O nome é simples assim como sua utilização.

td

A instalação da mesma é pra la de trivial. O download pode ser feito aqui.

cd /usr/local/src/
wget -c http://arker.homelinux.org/files/td-0.4.tar.gz
tar -zxvf td-0.4.tar.gz
cd td-0.4
./configure
make && make install

Se ao executar aparecer um erro como esse:

$ td
Traceback (most recent call last):
File "/usr/local/bin/td", line 21, in ?
  from dateutil.relativedelta import *
ImportError: No module named dateutil.relativedelta

significa que não foi encontrada uma biblioteca do python: python-dateutils

No gento ela está no portage. Logo um simples comando resolve:

emerge dev-python/python-dateutil

Agora sim!!!

Vou resumir alguns comandos aqui e no final coloco o link novamente com todos os comandos.

Quando executado sem parâmetros o td exibe uma lista com as tarefas pendentes.

A saída acima contém o número da tarefa, a prioridade, a data da criação, e a descrição da mesma. O número da tarefa é importante para fazer referência a ela em outros comandos do td.
Não está no screenshot acima mas é exibida uma linha, no final, informando quantas tarefas estão sendo exibidas e quantas estão ocultas.

Nota: Quando for exibido um caracter # significa que é o número da tarefa. Exibido ao executar o td sem argumentos.

Adicionar um tarefa:

td add Comprar ingressos para o show das Marcianas... blehhh

Deletar uma tarefa:

td del #

Priorizar uma tarefa:

td pri # A

As prioridades são letras A, B, C... essas 3 tem cores diferentes ao serem listadas. do D em diante é apenas um verde escuro.

Por padrão tarefas recém-adicionadas não tem prioridade nenhuma. Caso deseja-se remover a prioridade de uma tarefa, usa-se:

td pri #

Marcando uma tarefa como completa:

td done #

A partir de agora ele não é mais exibida ao digitar td.


Exibindo a lista das tarefas completas:

td done

Marcando uma tarefa completa como incompleta:

td undo #

Substituindo uma tarefa:

td rep # passear com o cachorro

cansei... mais detalhes aqui:
http://djcraven5.blogspot.com/2006/12/td-command-line-todo-list-manager.html

Atalhos de teclado no Gnome

Afim de facilitar o dia-a-dia e fazer uso da tecla com o símbolo do Windows, a.k.a, Super. Fui atrás de algumas dicas de como criar teclas de atalho com a mesma.

Todas alterações aqui são feitas utilizando o gconf-editor.


Super + e -> Abre o Nautilus (a la Windows Explorer)


Navegue até /apps/metacity/keybinding_commands/

Aí você vai encontrar chaves com o nome formado da seguinte maneira: command_N. Onde N é o número de 1 a 12.

Escolha uma qualquer que o valor esteja em branco, acredito que se nunca tenha alterado todas devem estar em branco. Edita a chave e no campo valor coloque o comando que deseja ser executado. Nesse caso:

nautilus --browser

Ótimo. Agora que já setamos o comando, devemos escolher a tecla de atalho para executá-lo.
Navegue até /apps/metacity/global_keybindings/

Aí voce vai encontrar chaves com o nome formado da seguinte maneira: run_command_N. Onde N é um número de 1 a 12. Coincidência?! Não!!! Coincidência são 24 cervejas em uma caixa e 24 horas em um dia. Mas neste caso essa chaves conterão a seqüência de teclas para os respectivos comandos ajustados anteriormente.

Se você tem problemas em compreender as coisas eu poderia desenhar pra ficar mais fácil, mas vai demorar e eu to sem tempo. Mas vou exemplificar que aí sim! Caso AINDA não entenda é melhor você começar a pensar em um concurso público ou se candidatar a algum cargo político...

Brincadeirinha... eu queria dizer CC.

Suponhamos que a chave /apps/metacity/keybinding_commands/command_6 tem o valor gnome-terminal. Aí na chave /apps/metacity/global_keybindings/run_command_6 você coloca algo como "<alt>F5", sem aspas, no valor. tcharã... agora toda vez que você pressionar Alt+F5 o terminal do gnome vai se abrir :-D... Não é fantástico?!?!

Bom.. mas o que deve ser salientado é que gostaríamos de usar a combinação de teclas Super + e
Em alguns lugares encontrei que o código da tecla é <super_l>. Não é mentira... mas para fazer a combinação com outras teclas devemos usar <mod4>. Dessa forma, nossa sequência de teclas que representa Windows+e fica assim:

<mod4>e

Super + d -> Mostra o Desktop

Bom... agora você já está craque. Porém já existe esta ação pronta. Logo não precisamos definir o comando, mas apenas a combinação das teclas.

Navegue até /apps/metacity/global_keybindings/show_desktop e defina no valor:

<mod4>d

Links consultados:
link 1
link 2

Personalizações

Vou reunir algumas alterações que adoto como padrão nas máquinas desktop ou servers onde tenho contato. Acho interessante se adaptar a um determinado comportamento para que se consiga produzir mais em menos tempo.

Screen:

/etc/screenrc

#Enable UTF8 for input/output
defutf8 on

# Default encoding
defencoding ISO8859-15

# Automatically detach on hangup.
autodetach on

# Don't display the copyright page
startup_message off

# Change default scrollback value for new windows
defscrollback 1000

vbell on
vbell_msg " Mooo ---- Moo!! "

# Welcome the user:
echo "welcome :-)"
sleep 1

Shells:

Gentoo:
/etc/rc.conf

EDITOR="/usr/bin/vim"

/etc/inputrc

#http://lutierigb.blogspot.com/2008/03/bash-buscando-no-histrico-estilo-csh.html

"\e[5~": history-search-backward
"\e[6~": history-search-forward

bash -> /etc/profile.d/aliases.sh

alias ls="ls -F --color"
alias grep="grep --colour"
alias egrep="egrep --colour"

FreeBSD

shell csh -> /etc/csh.cshrc

alias ls ls -FG
alias grep grep --colour
alias egrep egrep --colour

shell sh - > /etc/profile

PS1="`whoami`@`hostname | sed 's/\..*//'`"
case `id -u` in
0) PS1="${PS1}# ";;
*) PS1="${PS1}$ ";;
esac

alias ls="ls -FG"
alias grep="grep --colour"
alias egrep="egrep --colour"

Relay host no Sendmail

Coisa estranha é o arquivo de configuração do sendmail. O sendmail.cf. Para mim, no FreeBSD, está localizado sob /etc/mail/

Bom, não vou falar da sintaxe do arquivo.

Meu cenário é o seguinte: Tenho um servidor de e-mails em RH com postfix e todas parafernalhas que fazem parte da vida de um pobre admin de e-mail. Tenho alguns outros servers que também precisam enviar e-mail para fora rodando sendmail. Porém, esses outros servers não tem acesso direto a internet. Logo os e-mails não podem ser enviados diretamente.

O que eu precisava e encontrei com facilidade, inclusive vasculhando o sendmail.cf e depois confirmando no google, era despachar todos os e-mails desses outros servers para o RH. O nome do servidor que receberá os e-mails é chamado de Relay Host. E ele sim faria o serviço de mandar pela internet.

No arquivo sendmail.cf procure por uma linha iniciada por DS. E acrescente o nome do servidor para onde os e-mails devem ser encaminhados. Por exemplo:

DSmail.empresa.com.br

É sem espaço mesmo o_O

Reinicie o serviço e teste.

crie um arquivo chamado email com o seguinte conteúdo:

To: emailqualquer@gmail.com
From: root@plenaxx.ch
Subject: Um teste

Isto eh um teste.
(linha vazia)

Envie esse arquivo usando o sendmail.

cat email | /usr/sbin/sendmail -bm -t -v

Confirme o envia olhando a fila com o comando mailq e confirme o relay em /var/log/maillog.

Consultas:
http://www.akadia.com/services/sendmail_relay.html
http://www.ozzu.com/unix-linux-forum/how-setup-relay-host-sendmail-t29690.html

Documentação Cyrus-sasl

auth_ldap module for saslauthd
------------------------------

Saslauthd can use an LDAP directory for authentication/authorization.

Sections:
1. Build saslauthd with ldap support
2. Start saslauthd with ldap
3. Testing
4. Parameters
5. Examples
6. Notes
7. Todo
8. Feedback
8. Author


1. BUILD SASLAUTHD WITH LDAP SUPPORT
------------------------------------

Ensure that you have the OpenLDAP (http://www.openldap.org) libraries 2.0 or
higher.  Fetch the latest cyrus-sasl package, 2.1.12 or higher,
ftp://ftp.andrew.cmu.edu/pub/cyrus-mail/.

Unpack cyrus-sasl:
gzip -dc cyrus-sasl-2.1.12.tar.gz | tar xf -
or
tar zxf cyrus-sasl-2.1.12.tar.gz (if your tar supportz gzip)

cd cyrus-sasl-2.1.12
./configure --with-ldap  (you may need to add other options, check doc/index.html for more)
make
make install


2. START SASLAUTHD WITH LDAP
----------------------------

Create /usr/local/etc/saslauthd.conf and add the following (modify to fit your
environment):
ldap_servers: ldap://10.1.1.15/ ldap://10.1.1.25/
ldap_bind_dn: cn=operator,ou=Profile,o=foo.com
ldap_bind_pw: secret

Do not specify ldap_bind_* if you want to bind anonymously to your ldap server(s).

Run saslauthd:
saslauthd -a ldap

If you want to specify a different configuration file, you can do something
like:
saslauthd -a ldap -O /etc/saslauthd.conf

For more, check 'man saslauthd'


3. TESTING
----------

First build testsaslauthd:
cd $sasl_src/saslauthd
make testsaslauthd

Run test utility:
./testsaslauthd -u igor -p secret
0: OK "Success."

If you get output other then Success, check the auth.* syslog facility.
Hopefully this will give you enough information to make adjustements in the
startup and/or configuration files.


4. PARAMETERS
-------------

The following are available ldap parameters.  There are quite a few of those,
but only ldap_servers may need to be specified. The defaults for all other
parameters are adequate for most installations.

Do not use quotes (\"\') in the parameter values.  The defaults are specified
within the first set of <>.  There may be a second set of <> which provide
available values.

ldap_servers: <ldap://localhost/>
Specify URI(s) refering to LDAP server(s), e.g. ldaps://10.1.1.2:999/.
You can specify multiple servers separated by a space.

ldap_bind_dn: <none>

Specify DN (distinguished name) to bind to the LDAP directory.  Do not
specify this parameter for the anonymous bind.

ldap_bind_pw: <none>
Specify the password for ldap_bind_dn.  Do not specify this parameter
for the anonymous bind.

ldap_version: <3> <2|3>
Specify the LDAP protocol version to use.

ldap_timeout: <5>
Specify a number of seconds a search can take before timing out.

ldap_time_limit: <5>

Specify a number of seconds for a search request to complete.

ldap_deref: <none> <search|find|always|never>
Specify how aliases dereferencing is handled during a search.

ldap_referrals: <no>
Specify whether or not the client should follow referrals.

ldap_restart: <yes>
Specify whether or not LDAP I/O operations are automatically restarted
if they abort prematurely.

ldap_scope:

Search scope.

ldap_search_base: <none>
Specify a starting point for the search: e.g. dc=foo,dc=com.  Tokens
described in 'ldap_filter' (see below) can be used for substitution.

ldap_auth_method: <bind> <bind|custom|fastbind>
Specify an authentication method.

The bind method uses the LDAP simple bind facility to verify the
password.  This is the default.

The custom method uses userPassword attribute to verify the password.
Suppored hashes: crypt, md5, smd5, sha and ssha.  Cleartext is supported
as well.

The fastbind method does away with the search and extra anonymous bind
in auth_bind, but makes two assumptions:
 1. Expanding the ldap_filter expression gives the fully-qualified DN
 2. There is no cost to staying bound as a named user

ldap_filter: <uid=%u>
Specify a filter.  The following tokens can be used in the filter string:

%%   = %
%u   = user
%U   = user portion of %u (%U = test when %u = test@domain.tld)
%d   = domain portion of %u (%d = domain.tld when %u = test@domain.tld)
%1-9 = domain tokens (%1 = tld, %2 = domain when %d = domain.tld)
%s   = service
%r   = realm

The %u token has to be used at minimum for the filter to be useful.  If
ldap_auth_method is 'bind', the filter will search for the DN
(distinguished name) attribute.  Otherwise, the search will look for
the 'ldap_password_attr' (see below) attribute.

ldap_group_dn: <none>

Specify a group DN. If specified, the user DN has to be part of the
group in order to authenticate successfully.  Tokens described in
'ldap_filter' (see above) can be used for substitution.  The user DN is
compared against the 'ldap_group_attr' (see below) attribute of the
group.

ldap_group_attr: <uniqueMember>
Specify what attribute to compare the user DN against in the group. If
ldap_group_dn is not specified, this parameter is ignored.

ldap_password_attr: <userPassword>
   Specify what password attribute to use for password verification.

ldap_tls_check_peer: <no> <yes|no>
Require and verify server certificate.  If this option is yes,
you must specify ldap_tls_cacert_file or ldap_tls_cacert_dir.

ldap_tls_cacert_file: <none>

File containing CA (Certificate Authority) certificate(s).

ldap_tls_cacert_dir: <none>
Path to directory with CA (Certificate Authority) certificates.

ldap_tls_ciphers: <DEFAULT>
List of SSL/TLS ciphers to allow.  The format of the string is
described in ciphers(1).

ldap_tls_cert: <none>
File containing the client certificate.

ldap_tls_key: <none>
File containing the private client key.


5. NOTES
--------

For better performance ensure that the attributes specified in ldap_filter are
indexed.

My testing shows that 'custom' is 2-3 times faster than 'bind'
ldap_auth_method.  The 'fastbind' auth_method is just as fast or faster.  The
slower performace of the 'bind' auth_method is caused by two extra calls to
ldap_bind() per each authentication.

6. TODO
-------

- Port to other ldap libraries
- There may be bind problems when following referrals.  Normally this is not an
issue.
- Allow to specify an attribute other than userPassword for use in the custom
authentication method. (Done)
- Add more password hashes such as md5, sha etc (Done)
- Make a suggestion (possibly another authentication method?) (added fastbind)
thanks to Simon Brady <simon.brady@otago.ac.nz>


7. FEEDBACK
-----------

Feedback is much appreciated!  Please drop me a note if you are successfully
using ldap-enabled saslauthd.  Any code improvements and/or suggestion are welcome.

If you have questions, send email to cyrus-sasl@lists.andrew.cmu.edu.  Please
include relevant information about your saslauthd setup: at minimum provide
your saslauth.conf, output from syslog and which directory server you're using.


8. AUTHOR
---------

Igor Brezac <igor@ipass.net>.

Retirada daqui.

PF com problemas no boot[atualizado]

Logo após ter instalado e configurado um firewall em BSD usando PF me deparei com um simples, comum e impactante problema. O rc no bsd é o cara que carrega e lê os scripts de inicialização do sistema. Existem um ordem para carregá-los e essa ordem normalmente tem lógica. Por exemplo, não adianta carregar um serviço como NTP antes de ter acesso a internet.

Mas é exatamente essa ordem de carregamento do serviços que estava errada para a minha necessidade. O meu firewall estava sendo carregado antes das configurações de rede. Tudo bem.. beleza. Entretanto, eu tenho algumas regras baseadas em hosts e não IP's. Exemplo:

block quick from any to chatenabled.mail.google.com

Uma vez que a rede é "levantada" depois do firewall eu pergunto: Como o pobre firewall vai conseguir traduzir chatenabled.mail.google.com em IP?! Coisas do mundo moderno DNS. :-)

Para solucionar pode-se fazer uso da POG ou:

chmod o+w /etc/rc.d/pf
vi /etc/rc.d/pf

# REQUIRE: root mountcritlocal netif pflog pfsync networking

inserir na linha acima a palavra "networking"

:x
chmod o-w /etc/rc.d/pf

Isso diz que o serviço de networking é necessário para carregar o pf. Vale pra quem tem o mesmo problema com VPN's.

Pronto!!!

Mentira. Aquilo ali em cima acho que não funcionou.. mas enfim. Peço perdão e todos vivem felizes.

Consegui solucionar esse problema alterando a ordem dos scripts na inicialização. O trecho abaixo mostra a comparação entre os arquivos originais e a modificação que é necessária fazer.

----snip------
upmefirewall# diff -ruN /etc/rc.d/ /home/lutierib/etc/rc.d/
diff -ruN /etc/rc.d/NETWORKING /home/lutierib/etc/rc.d/NETWORKING
--- /etc/rc.d/NETWORKING Fri Jan 12 04:13:15 2007
+++ /home/lutierib/etc/rc.d/NETWORKING Mon Mar 24 17:28:13 2008
@@ -7,6 +7,7 @@
# PROVIDE: NETWORKING NETWORK
# REQUIRE: netif routing network_ipv6 isdnd ppp
# REQUIRE: routed mrouted route6d mroute6d
+# BEFORE: pf

# This is a dummy dependency, for services which require networking
# to be operational before starting.
diff -ruN /etc/rc.d/pf /home/lutierib/etc/rc.d/pf
--- /etc/rc.d/pf Mon Mar 24 17:51:16 2008
+++ /home/lutierib/etc/rc.d/pf Mon Mar 24 17:27:05 2008
@@ -5,7 +5,6 @@

# PROVIDE: pf
# REQUIRE: root mountcritlocal netif pflog pfsync
-# BEFORE: routing
# KEYWORD: nojail

. /etc/rc.subr
upmefirewall#

----snip------

Resumindo a saída do diff acima:

Dois arquivos são alterados. São eles: NETWORKING e pf.
No arquivo NETWORKING adiciona-se a linha: # BEFORE: pf
E no arquivo pf remove-se a linha: # BEFORE: routing



Para verificar a ordem que os scripts serão carregados:

rcorder /etc/rc.d/* /usr/local/etc/rc.d/*

Atualizando o ports e preservado as opções anteriores

O freebsd utiliza um ferramenta pra atualizar os pacotes(ports) instalados que é o portupgrade. Ele é inteligentizinho, mas nem tanto quanto eu queria que fosse.

portupgrade squid, por exemplo, baixa o fonte do squid, baixas patches(caso existam), aplica os patches, compila utilizando as últimas opções usadas(na última compilação), remove a versão anterior, instala e registra essa versão recém-compilada. Muito bem!

Quando eu disse que ele, compila utilizando as últimas opções usadas, me refiro a um arquivo em /var/db/ports/<nome>/options.

Esse arquivo é criado quando é executado o make config. Que exibe um tela ncurses com algumas opções pra compilação. Aí depende de cada ports. Alguns trabalham com essa forma de selecionar o que vai ser habilitado/desabilitado outros não. Caso o ports use OPTIONS no Makefile e exista esse arquivo citado acima, toda vez que for executado o make ou make install, inclusive a partir do portupgrade, essas opções serão utilizadas para compilação sem exibir a tela para selecionar. Caso o ports use OPTIONS no Makefile e NÃO exista esse arquivo citado, a tela será exibida, o arquivo então será criado com as opções selecionadas, e a compilação ocorrerá normalmente. E todas as futuras compilações utilizarão essas mesmas opções.

Um problema comum é o Makefile não fazer uso do OPTIONS ou mesmo fazer uso e não ter todas as opções inclusas. Uma vez que apenas escolhe-se se quer ou se não quer uma determinada opção, opções que o valor é string, exemplo:

SQUID_DEFAULT_LANG=Portuguese

Não são exibidas nessa tela ncurses. Pois lá só existe um checkbox e ponto.

O portuprgade utiliza um arquivo de configuração que nos diz que pode ser especificado argumentos de compilação em /usr/local/etc/pkgtools.conf da seguinte maneira:

MAKE_ARGS = {
# a) Separate them with the space
'databases/mysql41-*' => 'WITH_LINUXTHREADS=1 SKIP_DNS_CHECK=1',

# b) Specify them using an array
'databases/mysql41-*' => [
'WITH_LINUXTHREADS=1',
'SKIP_DNS_CHECK=1',
],
}

Muito bom, resolve meu problema, massssssss.... se um dia eu for atualizar diretamente pela árvore do ports, sem utilizar o portupgrade, aí ferrou!! As opções não serão utilizadas. Uma vez que quem lê esse arquivo é o aplicativo portupgrade.

Cansei... de escrever... mais opções leia esse artigo.
http://blog.innerewut.de/2006/1/14/upgrading-ports-and-preserve-make-options

Resumindo, pra compilar o mesmo ports sempre, forever and ever, com as mesmas opções, independente do modo de atualização/instalação. Adicione o seguinte no /etc/make.conf:

.if ${.CURDIR:M*www/squid}
NO_KERBEROS=yes
SQUID_CONFIGURE_ARGS=--enable-dlmalloc --enable-async-io --with-pthreads --with-aio --enable-ntlm-fail-open
SQUID_LANGUAGES=English Portuguese
SQUID_DEFAULT_LANG=Portuguese
.endif

Quando a compilação ocorre, independente do método usado, o make entra no diretório do ports.

O que o código acima faz é ver se o make está dentro de algum diretório que termine com www/squid. Caso esteja ele setará aquelas variáveis dentro bloco do if.

Como eu sou pior que São Tomé. Precisei testar pra ver se realmente funcionava antes de compilar. No caso do código acima é simples:

# cd ~
# make -V SQUID_CONFIGURE_ARGS
# cd /usr/ports/www/squid
# make -V SQUID_CONFIGURE_ARGS
--enable-dlmalloc --enable-async-io --with-pthreads --with-aio --enable-ntlm-fail-open

Viu! Funcionou!
'make -V VARIAVEL' retorna o valor da variável especificada.


Bye...