Sobre o vexame da Seleção Brasileira na Copa do Mundo de 2014.

Crônica de Carlos Drummond de Andrade, publicada em 7 de julho de 1982, no Jornal do Brasil.

Perder, Ganhar, Viver

Vi gente chorando na rua, quando o juiz apitou o final do jogo
perdido; vi homens e mulheres pisando com ódio os plásticos
verde-amarelos que até minutos antes eram sagrados; vi bêbados
inconsoláveis que já não sabiam por que não achavam consolo na
bebida; vi rapazes e moças festejando a derrota para não deixarem de
festejar qualquer coisa, pois seus corações estavam programados para
a alegria; vi o técnico incansável e teimoso da Seleção xingado de
bandido e queimado vivo sob a aparência de um boneco, enquanto o
jogador que errara muitas vezes ao chutar em gol era declarado o
último dos traidores da pátria; vi a notícia do suicida do Ceará e
dos mortos do coração por motivo do fracasso esportivo; vi a dor
dissolvida em uísque escocês da classe média alta e o surdo clamor de
desespero dos pequeninos, pela mesma causa; vi o garotão mudar o
gênero das palavras, acusando a mina de pé-fria; vi a decepção
controlada do presidente, que se preparava, como torcedor número um
do país, para viver o seu grande momento de euforia pessoal e
nacional, depois de curtir tantas desilusões de governo; vi os
candidatos do partido da situação aturdidos por um malogro que lhes
roubava um trunfo poderoso para a campanha eleitoral; vi as oposições
divididas, unificadas na mesma perplexidade diante da catástrofe que
levará talvez o povo a se desencantar de tudo, inclusive das
eleições; vi a aflição dos produtores e vendedores de bandeirinhas,
flâmuIas e símbolos diversos do esperado e exigido título de campeões
do mundo pela quarta vez, e já agora destinados à ironia do lixo; vi
a tristeza dos varredores da limpeza pública e dos faxineiros de
edifícios, removendo os destroços da esperança; vi tanta coisa, senti
tanta coisa nas almas.

Chego à conclusão de que a derrota, para a qual nunca estamos
preparados, de tanto não a desejarmos nem a admitirmos previamente, é
afinal instrumento de renovação da vida. Tanto quanto a vitória
estabelece o jogo dialético que constitui o próprio modo de estar no
mundo. Se uma sucessão de derrotas é arrasadora, também a sucessão
constante de vitórias traz consigo o germe de apodrecimento das
vontades, a languidez dos estados pós-voluptuosos, que inutiliza o
indivíduo e a comunidade atuantes. Perder implica remoção de
detritos: começar de novo.

Certamente, fizemos tudo para ganhar esta caprichosa Copa do Mundo.
Mas será suficiente fazer tudo, e exigir da sorte um resultado
infalível? Não é mais sensato atribuir ao acaso, ao imponderável, até
mesmo ao absurdo, um poder de transformação das coisas, capaz de
anular os cálculos mais científicos? Se a Seleção fosse à Espanha,
terra de castelos míticos, apenas para pegar o caneco e trazê-lo na
mala, como propriedade exclusiva e inalienável do Brasil, que mérito
haveria nisso? Na realidade, nós fomos lá pelo gosto do incerto, do
difícil, da fantasia e do risco, e não para recolher um objeto
roubado. A verdade é que não voltamos de mãos vazias porque não
trouxemos a taça. Trouxemos alguma coisa boa e palpável, conquista do
espírito de competição. Suplantamos quatro seleções igualmente
ambiciosas e perdemos para a quinta. A Itália não tinha obrigação de
perder para o nosso gênio futebolístico. Em peleja de igual para
igual, a sorte não nos contemplou. Paciência, não vamos transformar
em desastre nacional o que foi apenas uma experiência, como tantas
outras, da volubilidade das coisas.

Perdendo, após o emocionalismo das lágrimas, readquirimos ou
adquirimos, na maioria das cabeças, o senso da moderação, do real
contraditório, mas rico de possibilidades, a verdadeira dimensão da
vida. Não somos invencíveis. Também não somos uns pobres diabos que
jamais atingirão a grandeza, este valor tão relativo, com tendência a
evaporar-se. Eu gostaria de passar a mão na cabeça de Telê Santana e
de seus jogadores, reservas e reservas de reservas, como Roberto
Dinamite, o viajante não utilizado, e dizer-lhes, com esse gesto, o
que em palavras seria enfático e meio bobo. Mas o gesto vale por
tudo, e bem o compreendemos em sua doçura solidária. Ora, o Telê!
Ora, os atletas! Ora, a sorte! A Copa do Mundo de 82 acabou para nós,
mas o mundo não acabou. Nem o Brasil, com suas dores e bens. E há um
lindo sol lá fora, o sol de nós todos.

E agora, amigos torcedores, que tal a gente começar a trabalhar, que
o ano já está na segunda metade?

Anúncios

Configuração Switchs Extreme – MLAG-LACP

Configuração Switchs Extreme 650T – MLAG-LACP

Sumário

Este documento visa facilitar o entendimento do funcionamento da Tecnologia MLAG-LACP – Multi Chassis Link Aggregation. Que permitirá o funcionamento de forma homologada as Blades DELL instaladas no ambiente do IDC.

O que é LAG e como funciona?

Na verdade, LACP ou Link Aggregation Control Procol é uma tecnologia bastante usada que lhe permite combinar várias interfaces paralelas em um único link virtual (a partir da perspectiva STP). Com a combinação de interfaces paralelas sendo substituídos por um único link virtual o STP não detecta loops e todas as conexões físicas podem ser utilizadas normalmente.

lag

Figura 1 – Representação gráfica do LACP do ponto de vista Físico.

 

O que é MLAG e como funciona?

Multi-Chassis LAG é uma tecnologia emergente que é destinado principalmente a resolver os problemas relacionados a ineficiências no Spanning-Tree Protocol (STP) em ambientes de data center. Normalmente, em topologias de Agregação de link, dois dispositivos envolvidos estão diretamente conectados. Imagine que você tivesse duas Switchs físicas usando um único Stack. Então as conexões destas Switchs físicas funcionarão dentro de um mesmo Stack e você poderá agregá-las. Com isso o fundamento sobre a Tecnologia Multi-Chassis Link Aggregation (MLAG) está explicado.

mlag_1

Figura 2 – Representação gráfica do MLAG do ponto de vista Físico

MLAG é a estratégia mais simples de Multipath Layer 2 que os fornecedores oferecem hoje em dia. O MLAG permite que vários switches físicos se apresentem para outros dispositivos em uma rede como um único switch, embora cada Switch continua a ser gerenciada de forma independente. Isso permite que você conecte de forma múltipla um host físico sendo uma interface conectada a cada uma das Switchs no grupo MLAG enquanto encaminha dados ativamente em todos os links no lugar de se ter apenas alguns links ativos e desperdiçando alguns outros enquanto eles estão em Standby pelo tradicional STP. O LACP (802.3ad) é comumente usado para fazer a comutação destes links.

mlag_2

Figura 3 – Representação gráfica de conexões entre Switchs usando MLAG no Stack de Switchs principal e um Dispositivo ou Host na outra extremidade.

 

Sugestão de implantação

O motivador principal seria manter o nível de conectividade entre VLANs também redundante. O STP de alguma forma nos atenderia em parte, mas o formato de funcionamento do STP que é baseado em vedar um link e liberar outro baseado em demanda, não nos traria sucesso visto que a necessidade seria o balanceamento da carga de conexão.

 

Vantagem e desvantagens no uso do MLAG

Vantagens

  • Pode ser montado em um LAG existente.
  • É implementado pela maioria dos fabricantes alguns necessitam apenas de um upgrade de Firmware.

Desvantagens

  • A adição física de interfaces a um peer MLAG nem sempre resulta em uma agregação de banda proporcional.
  • Existe algum nível de compatibilidade entre vendors e o MLAG, no entanto isso nem sempre funciona, a recomendação é que se utilize equipamentos iguais.
  • É muito importante entender que um peer MLAG continuam sendo dois Switchs Físicos com seu próprio gerenciamento. Portanto a comunicação entre Switchs deve ser mantida para assegurar estabilidade, uma falha de empilhamento (stack) poderá causar problemas.

Passos a serem executados

Como apresentado no artigo acima vamos utilizar os protocolos MLAG (Multi Chassis Link Aggregation Protocol) e LACP (Link Aggregation Control Protocol – IEE 802.3ad).

Os benefícios principais desta Tecnologia é o aumento de banda disponível e a alta-disponibilidade de conexão.

Seguem abaixo os comando utilizados no lado da Switch Extreme Summit X650T para habilitar esta tecnologia:

Extreme Summit X650T

Slot-1 X650-CORE # enable sharing 1:29 grouping 1:29 algorithm address-based L3_L4 lacp
Slot-1 X650-CORE # enable sharing 2:29 grouping 2:29 algorithm address-based L3_L4 lacp

Traduzindo os comandos acima: o “sharing” ativa o recurso de agregação de portas, os números significam as portas que serão utilizadas.

Após executados os comandos acima temos duas portas em cada Switch que respondem como uma apenas, e então podemos avançar para a definição de VLANs.

Para definir as associações de VLANs as portas com LACP executamos os seguintes comandos:

Extreme Summit X650T

Slot-1 X650-CORE # configure vlan RNP_DMZ add ports 1:29, 2:29 tagged
Slot-1 X650-CORE # configure vlan RNP_DMZL add ports 1:29, 2:29 tagged
Slot-1 X650-CORE # configure vlan RNP_EXT add ports 1:29, 2:29 tagged
Slot-1 X650-CORE # configure vlan RNP_INT add ports 1:29, 2:29 tagged
Slot-1 X650-CORE-11ANDAR.1 # configure vlan RNP_WIFI add ports 1:29, 2:29 tagged

Traduzindo os comandos acima; Temos a necessidade de transmitir todas as Tags através destas portas visto que a Switch do Chassis das Blades será configurado para interpretar todas elas, o que significa que todo a infra será em Camada 2 enquanto que a Camada 3 continuará a ser tratada apenas pelo Firewall e o Roteador.

Feito isso efetuamos as conexões físicas e iniciamos a migração das regras.

Seguem abaixo os passos para criarmos os peers MLAG.

Extreme Summit X650T

Slot-1 X650-CORE # create mlag "peer1"
Slot-1 X650-CORE # configure mlag peer "peer1" lacp-mac 00:11:22:33:44:55
Slot-1 X650-CORE # enable mlag port 1:29 peer "peer1" id 1
Slot-1 X650-CORE # enable mlag port 2:29 peer "peer1" id 1
Slot-1 X650-CORE #

 

 

 


SSSD: Bug utilizando Criptografia TLS em implementações (LDAP+Kerberos+GSSAPI).

Informação Importante!

A implementação do SSSD (LDAP+Kerberos+GSSAPI) não requer criptografia TLS para conexões TLS ou SSL, foram detectados problemas ao se configurar a conexão LDAP+TLS+GSSAPI tendo em vista que o mecanismo do GSSAPI falha ao tentar estabilizar o contexto de segurança da negociação quando um conexão TLS vier a falhar.

Referências: https://tools.ietf.org/html/rfc5056


Configurando Switch Extreme Summit x650 Series.

Utilizando o protocolo LACP (Link Aggregation Control Protocol).

A Switch Extreme demonstrou certa facilidade para configurar este protocolo, para quem não sabe este protocolo permite aumentarmos a capacidade de banda agrupando duas ou mais portas para que se comportem como uma apenas.

A Extreme apelida este recurso com um nome mas isso não muda seu funcionamento, eles o chamam de Load Sharing e para ajudar a entender melhor segue uma imagem de um agrupamento de portas:

summit

Na prática fica assim:

enable sharing <master_port> grouping <portlist>

disable sharing <master_port>

Exemplo:  enable sharing 9 grouping 9-12

Lembre que quando estiver usando o Load Sharing você deve sempre referenciar a porta master do grupo load-sharing (no exemplo porta 9).

Criando VLANs

Para criar VLANs a Extreme também não resolveu complicar, no caso o que precisamos saber é se a VLAN a ser criada precisará ser propagada para outras switchs.

Caso positivo nós devemos “taggear” os segmentos pois somente assim outras switchs saberão o que fazer com os segmentos.

Caso negativo nós aplicamos o “untagged” que apenas aplica o tag VLAN aos pacotes entrantes.

Na prática vemos abaixo.

– Com tag:

create vlan sales

config sales tag 120

config sales add port 1-3 tagged

– Sem tag:

create vlan it

config sales tag 140

config sales add port 4-7 tagged

Listando as VLANs:

show vlan all

Por hoje é só!

Um abraço a todos.


.ılı.ılı. CiscoBlog Brasil .ılı.ılı. » Introdução a plataforma Extreme Networks + Guia de comandos

Procurando por informações sobre experiência com equipamentos da Extreme Networks esbarrei neste post que me permitiu ter um visão bem sucinta dos procedimentos de configuração.

Agradecimentos ao nosso amigo Diogo Mendes  http://flavors.me/diogoserrano.

.ılı.ılı. CiscoBlog Brasil .ılı.ılı. » Introdução a plataforma Extreme Networks + Guia de comandos.


389/RHDS memberOf plugin

Olá pessoal pra quem ainda não sabe o 389/Red Hat Directory Server (RHDS) tem o plugin “memberOf” (começando na versão Fedora DS 1.1.1, com grandes melhorias a partir de 389-DS 1.2.7, e desde o RHDS v8.1), que oferece a mesma funcionalidade como o recurso “memberOf” do Active Directory.

O plugin memberOf está desativado por padrão tanto no 389 quanto no RHDS. Uma vez ativado ele irá mostrar os valores de dn de todos os grupos como uma entrada no atributo memberOf. Ele funciona adicionando um atributo e o valor de entrada automaticamente, quando eles são adicionados a um grupo. Diferente da funcionalidade similar “isMemberOf” da última versão do Sun/Oracle Directory Server Enterprise Edition, memberOf retorna como um atributo de usuário padrão e, portanto, não precisa ser especificado explicitamente em uma pesquisa.

Pelo fato de ser um atributo standard, para adicionar o memberOf a uma entrada, pelo menos um objectclass deve ser incluido como um atributo permitido. O novo esquema 389/RHDS inclui a classe de objeto inetUsr, que permite memberOf.

[me@emyhost ~]$ ldapsearch -x -LLL -h localhost -D "cn=directory manager" 
-W -b "dc=example,dc=com" -s sub "uid=me"
Enter LDAP Password: 
dn: uid=me,ou=People,dc=example,dc=com
givenName: My
sn: Test
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
objectClass: inetUser
uid: me
* * *
memberOf: cn=Directory Administrators,dc=example,dc=com
memberOf: cn=Staff,ou=Groups,dc=example,dc=com
memberOf: cn=Users,ou=Groups,dc=example,dc=com

Para ativar o plugin, usar o console gui ou simplesmente alterar o valor de “nsslapd-pluginEnabled” em “cn=memberOf Plugin, cn=plugins, cn=config” de “off” para “on”. Se o diretório usa “uniquemember” em vez de “membro” como o atributo de membro do grupo, a primeira entrada deve ser substituída por este último na “memberofgroupattr”. Aqui estão algumas LDIFs para fazer o trabalho (aplicar usando ldapmodify):

dn: cn=memberOf Plugin,cn=plugins,cn=config
changetype: modify
replace: nsslapd-pluginenabled: on
-
replace: memberofgroupattr
memberofgroupattr: uniquemember

O plugin é então ativado após reiniciar o serviço de diretório.

Para modificar membros de grupos existentes (como um plugin do post-operation ele irá adicionar o atributo memberOf apenas para os membros do grupo recém-adicionados), o script de correção-memberof.pl está incluido. Ele pode ser encontrado em /usr/lib64/dirsrv/slapd-[nomedainstância]. A sintaxe fica assim:

fixup-memberof.pl -v -D "cn=directory manager" -w - 
 -b "dc=example,dc=com"

O script funciona ajustando o memberOf task no diretório. Isso pode ser feito manualmente, adicionando a seguinte entrada:

dn: cn=example memberof,cn=memberof task,cn=tasks,cn=config
objectclass: extensibleObject
cn:example memberof
basedn: ou=people,dc=example,dc=com
filter: (objectclass=groupofuniquenames)

(use ldapadd, ou ldapmodify com o parametro “-a”)

Referência: http://onemoretech.wordpress.com/2011/11/23/389rhds-memberof-plugin/


Configurando um DHCP com suporte a Múltiplas Subnets

Então pessoal, configurar um Servidor DHCP em Linux é uma tarefa fácil no entanto quando precisamos de maiores recursos isso pode se tornar uma dor de cabeça.

No meu caso eu estou utilizando uma Switch Layer 3 da marca Foundry modelo FastIron Edge X424 conforme artigo anterior e ela é parte essencial no funcionamento deste modelo de DHCP Server, então vamos lá.

Primeiramente instale o pacote do DHCP Server, no meu caso usei o Ubuntu 12.04.1 LTS, execute o comando:

apt-get install isc-dhcp-server

Depois de instalado o pacote vamos configurá-lo:

vim /etc/dhcp/dhcpd.conf

# option definitions common to all supported networks…
option domain-name “sci2013.org”;
option domain-name-servers  8.8.8.8;
authoritative;
default-lease-time 600;
max-lease-time 7200;

# Use this to enble / disable dynamic dns updates globally.
#ddns-update-style none;

# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
#authoritative;

# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;
subnet 192.168.1.0 netmask 255.255.255.0 {
option routers 192.168.1.254;
range 192.168.1.1 192.168.1.250;
}

subnet 192.168.2.0 netmask 255.255.255.0 {
option routers 192.168.2.254;
range 192.168.2.20 192.168.2.200;
group {
host Instrutor4 {
hardware ethernet 74:86:7a:fb:f9:11;
fixed-address 192.168.2.6;
}
host Webconf4 {
hardware ethernet 74:86:7a:fb:f9:10;
fixed-address 192.168.2.7;
}
}
}

subnet 192.168.3.0 netmask 255.255.255.0 {
option routers 192.168.3.254;
range 192.168.3.10 192.168.3.200;
}
subnet 192.168.4.0 netmask 255.255.255.0 {
option routers 192.168.4.254;
range 192.168.4.10 192.168.4.100;

}

Configurando a Foundry a fim de permitir que os broadcasts dos hosts sejam direcionados para o DHCP Server a partir de cada Vlan individualmente configurada permitindo que o DHCP Server consiga decidir a qual subnet cada host pertence.

Lembrando que para que as configurações tenham efeito as Vlans devem estar configuradas e funcionando.

SSH@FESX424 Router(config)#interface ve 110

SSH@FESX424 Router(config-vif-110)#ip helper-address <IP>

Isso irá habilitar o encaminhamento de datagramas UDP em broadcast para o IP do DHCP Server, sem isso seu servidor ficará sem efeito.

É isso pessoal até…