Referências Livro "Infrastructure as Code" - Kief Morris

Referências do Livro "Infrastructure as Code" - Kief Morris (References)

• Preface
• Andrew Caly Shafer and Patrick Debois triggered the DevOps movement with a talk at the Agile 2008 conference (http://www.jedi.be/presentations/agile-infrastructure-agile-2008.pdf). The movement grew, mainly driven by the series of DevOpsDays (https://www.devopsdays.org/) conferences organized by Debois.
  
• Chapter One
• https://martinfowler.com/bliki/TestDrivenDevelopment.html
• https://www.martinfowler.com/articles/continuousIntegration.html
• https://martinfowler.com/books/continuousDelivery.html
• http://itrevolution.com/devops-culture-part-1/
• http://itknowledgeexchange.techtarget.com/cloud-computing/infrastructure-as-code/
• http://www.infrastructures.org/index.shtml
• http://wiki.fai-project.org/wiki/Main_Page
• http://www.nongnu.org/cvs/
• https://www.amazon.com/Visible-Ops-Handbook-Implementing-Practical-ebook/dp/B002BWQBEE
• https://en.wikipedia.org/wiki/Open_Space_Technology
• https://devcenter.heroku.com/articles/erosion-resistance
• https://www.slideshare.net/randybias/architectures-for-open-and-scalable-clouds
• https://www.slideshare.net/gmccance/cern-data-centre-evolution
• https://samj.net/2012/03/08/simplifying-cloud-reliability/
• https://martinfowler.com/books/dsl.html
• https://www.slideshare.net/BrianTroutwine1/automation-with-humans-in-mind-making-complex-systems-predictable-reliable-and-humane
  
•  Chapter Two
• https://www.nist.gov/programs-projects/cloud-computing
• https://en.wikipedia.org/wiki/Representational_state_transfer
• http://fog.io/
• http://boto3.readthedocs.io/en/latest/
• https://aws.amazon.com/pt/sdk-for-ruby/
• https://aws.amazon.com/pt/kinesis/
• https://en.wikipedia.org/wiki/Software-defined_networking
• http://cobbler.github.io/
• http://fai-project.org/
• https://theforeman.org/
• http://opencrowbar.github.io/
• https://en.wikipedia.org/wiki/Preboot_Execution_Environment
• http://www.linux-mag.com/id/6747/
• https://aws.amazon.com/pt/solutions/case-studies/suncorp/
• http://fortune.com/2016/02/25/yes-banks-do-use-aws/
• http://www.computerworlduk.com/cloud-computing/how-tesco-bank-has-adopted-aws-cloud-as-business-as-usual-in-eight-months-3629767/
• https://ico.org.uk/for-organisations/guide-to-data-protection/principle-8-international/
• https://mechanical-sympathy.blogspot.com.br/2011/07/why-mechanical-sympathy.html
  
• Chapter Three
• https://www.amazon.com/The-Practice-Cloud-System-Administration/dp/032194318X
• https://aws.amazon.com/pt/cloudformation/
• https://www.terraform.io/
• https://github.com/chef/chef-provisioning
• https://godoc.org/cloud.google.com/go
• https://zookeeper.apache.org/
• https://www.consul.io/
• https://github.com/coreos/etcd
  
•  Chapter Four
• http://jpmens.net/2012/07/14/ansible-pull-instead-of-push/
• https://en.wikipedia.org/wiki/Unikernel
• https://github.com/Netflix/aminator
• https://www.packer.io/
• http://techblog.netflix.com/2013/03/ami-creation-with-aminator.html
• https://medium.com/s-c-a-l-e/microservices-monoliths-and-laser-nail-guns-how-etsy-finds-the-right-focus-in-a-sea-of-cf718a92dc90#.y19ax9ywf
• http://radar.oreilly.com/2013/11/polyglot-programming-what-is-it-and-why-should-you-be-using-it.html
• https://www.docker.com/
• https://coreos.com/blog/rocket.html
• https://docs.cloudfoundry.org/concepts/architecture/warden.html
• https://docs.microsoft.com/pt-br/virtualization/windowscontainers/about/index
• http://shop.oreilly.com/product/0636920033158.do
• http://blog.microscaling.com/2015/10/microscaling-in-box.html
• https://coreos.com/why/
• https://technet.microsoft.com/windows-server-docs/get-started/getting-started-with-nano-server
• http://rancher.com/rancher-os/
• https://developer.ubuntu.com/core
• https://blog.docker.com/2015/08/content-trust-docker-1-8/
  
• Chapter Five 
• http://peter.gillardmoss.me.uk/blog/2013/05/28/monitor-dont-log/
• http://alistair.cockburn.us/Information+radiator
• https://martinfowler.com/bliki/CommunalDashboard.html
• https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/
• https://www.gocd.io/
• https://jenkins.io/index.html
• https://www.jetbrains.com/teamcity/
• https://www.atlassian.com/software/bamboo
• https://martinfowler.com/articles/microservices.html
• https://martinfowler.com/bliki/MicroservicePrerequisites.html
• http://highscalability.com/amazon-architecture
  
•  Chapter Six
• http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-retirement.html
• https://launchpad.net/cloud-init
  
•  Chapter Seven
• https://en.wikipedia.org/wiki/Just_enough_operating_system
• https://www.packer.io/docs/builders/amazon-chroot.html
  
•  Chapter Eight
• https://www.thoughtworks.com/insights/blog/rethinking-building-cloud-part-4-immutable-servers
• http://nixos.org/
• https://docs.chef.io/berkshelf.html
• https://github.com/voxpupuli/librarian-puppet
• https://docs.puppet.com/pe/latest/r10k.html
  
•  Chapter Nine
• https://www.slideshare.net/gsilverm/aws-vpc-in
  
•  Chapter Ten
• http://agilemanifesto.org/
• http://agilemanifesto.org/principles.html
• http://www.extremeprogramming.org/
• http://paulhammant.com/2013/04/05/what-is-trunk-based-development/
• https://martinfowler.com/articles/continuousIntegration.html#FixBrokenBuildsImmediately
• https://martinfowler.com/articles/nonDeterminism.html
• https://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912
• http://tastycupcakes.org/2011/10/continuous-integration-with-lego/
• https://continuousdelivery.com/2010/08/continuous-delivery-vs-continuous-deployment/
• https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship-ebook/dp/B001GSTOAM
• https://martinfowler.com/bliki/TechnicalDebtQuadrant.html
• https://martinfowler.com/articles/feature-toggles.html
• http://lifeinvistaprint.com/techblog/configuration-management-git-consul/
  
•  Chapter Eleven
• https://docs.chef.io/chefspec.html
• https://codeascraft.com/2012/05/22/blameless-postmortems/
• http://serverspec.org/
• http://rspec.info/
• https://en.wikipedia.org/wiki/Lint_(software)
• http://puppet-lint.com/
• http://www.foodcritic.io/
• http://rspec-puppet.com/
• https://docs.saltstack.com/en/latest/topics/tutorials/writing_tests.html
• http://kitchen.ci/
• https://github.com/neillturner/kitchen-puppet
• https://dannorth.net/introducing-bdd/
• http://www.seleniumhq.org/
• https://en.wikipedia.org/wiki/Non-functional_requirement
• https://www.continuumsecurity.net/bdd-security/
• https://portswigger.net/burp/
• https://subgraph.com/vega/
• https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
• http://xunitpatterns.com/
• https://gdstechnology.blog.gov.uk/2015/03/25/test-driving-web-server-configuration/
• https://martinfowler.com/articles/mocksArentStubs.html
• https://martinfowler.com/books/refactoring.html
• https://martinfowler.com/bliki/StranglerApplication.html
• http://www.extremeprogramming.org/rules/pair.html
• https://martinfowler.com/bliki/PairProgrammingMisconceptions.html
• https://cucumber.io/
• http://docs.seleniumhq.org/
• https://www.infoq.com/interviews/george-dinwiddie-three-amigos
• http://www.jamesshore.com/Blog/Red-Green-Refactor.html
• https://martinfowler.com/bliki/TestDrivenDevelopment.html
  
•  Chapter Twelve
• https://martinfowler.com/bliki/DeploymentPipeline.html
• https://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912
• https://blog.magpiebrain.com/2009/12/13/a-brief-and-incomplete-history-of-build-pipelines/
• http://www.informit.com/articles/article.aspx?p=1621865&seqNum=2
• http://www.dropwizard.io/1.0.6/docs/
• https://www.thoughtworks.com/insights/blog/demystifying-conways-law
• https://www.thoughtworks.com/radar/techniques/inverse-conway-maneuver
• https://linux.die.net/man/1/reposync
• https://twitter.com/mini_inny
  
•  Chapter Thirteen
• http://wiki.c2.com/?LazinessImpatienceHubris
• https://www.amazon.com/The-Practice-Cloud-System-Administration/dp/032194318X
• https://www.vagrantup.com/
• https://www.youtube.com/watch?v=lsupJuAkfwQ
• https://github.com/chef/chef-rfc/blob/master/rfc019-chef-workflows.md
• http://paulhammant.com/2013/05/06/googles-scaled-trunk-based-development/
  
•  Chapter Fourteen
• https://www.amazon.com/Visible-Ops-Handbook-Implementing-Practical-ebook/dp/B002BWQBEE
• https://12factor.net/
• https://prometheus.io/
• https://samj.net/2012/03/08/simplifying-cloud-reliability/
• https://martinfowler.com/bliki/BlueGreenDeployment.html
• https://martinfowler.com/bliki/CanaryRelease.html
• http://agiletesting.blogspot.com.br/2009/07/dark-launching-and-other-lessons-from.html
• http://databaserefactoring.com/
• https://www.amazon.com/The-Practice-Cloud-System-Administration/dp/032194318X
• https://en.wikipedia.org/wiki/System_of_record
• https://en.wikipedia.org/wiki/Disaster_recovery
• http://techblog.netflix.com/2011/07/netflix-simian-army.html
• https://cve.mitre.org/
• https://www.venafi.com/assets/pdf/wp/Hearts-Continue-to-Bleed-Research-Report.pdf
• https://www.schneier.com/blog/archives/2015/12/back_door_in_ju.html
• https://github.com/dev-sec
• http://www.tripwire.com/state-of-security/security-data-protection/automation-action-proactively-hardening-systems-intrusion/
• http://www.tecmint.com/linux-server-hardening-security-tips/
• https://www.cyberciti.biz/tips/linux-security.html
• https://www.owasp.org/index.php/Application_Threat_Modeling
• http://www.infoworld.com/article/2608076/data-center/murder-in-the-amazon-cloud.html
• http://www.information-age.com/catastrophe-cloud-what-aws-hacks-mean-cloud-providers-123458406/
• https://www.amazon.com/dp/B00IG71FAS
• https://xkcd.com/936/
  
•  Chapter Fifteen
• http://www.ibm.com/developerworks/library/j-eaed1/
• https://www.mountaingoatsoftware.com/blog/spikes
• https://en.wikipedia.org/wiki/A/B_testing
• http://kief.com/tracer-bullet.html
• https://www.amazon.com/Agile-Experience-Design-Designers-Continuous/dp/0321804813
• http://shop.oreilly.com/product/0636920033851.do
• https://hbr.org/1993/09/why-incentive-plans-cannot-work
• https://www.amazon.com/Value-Stream-Mapping-Organizational-Transformation-ebook/dp/B00EHIEJLM
• https://www.amazon.com/Implementing-Lean-Software-Development-Addison-Wesley-ebook/dp/B00HNB3VQE
• https://www.amazon.com/Lean-Startup-Entrepreneurs-Continuous-Innovation-ebook/dp/B004J4XGN6
• http://shop.oreilly.com/product/0636920030355.do
• https://www.amazon.com/Kanban-David-J-Anderson-ebook/dp/B0057H2M70
• http://www.agileweboperations.com/scrum-vs-kanban
• https://www.iancarroll.com/2013/02/06/reflections-on-the-use-of-kanban-in-an-it-operations-team/
• https://www.amazon.com/Agile-Retrospectives-Making-Teams-Great/dp/0977616649
• https://leanpub.com/the-retrospective-handbook
• https://codeascraft.com/2012/05/22/blameless-postmortems/
• https://hbr.org/2015/06/75-of-cross-functional-teams-are-dysfunctional
• https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/
• http://www.allthingsdistributed.com/2016/03/10-lessons-from-10-years-of-aws.html
• http://wiki.c2.com/?UnixDesignPhilosophy
• https://www.amazon.com/UNIX-Philosophy-Mike-Gancarz/dp/1555581234/ref=sr_1_1?ie=UTF8&qid=1488047946&sr=8-1&keywords=unix+philosophy

Protótipo DIY E-Drum

    A facilidade que é trabalhar com Arduíno e aplicação dele em interfaces voltadas para música são muito interessantes. Há algum tempo tenho vontade de montar uma bateria eletrônica, agora estou executando esse projeto. Os objetivos são:

• Seja MIDI - Isso é para ser usado com softwares de VST ou DAW;
• Leia a intensidade da batida - Traduza a força da pancada no parâmetro MIDI velocity;
• Utilizar um Arduíno UNO ou Duemilanove - Este hardware só tem 6 saídas analógidas, logo é necessário utilizar um Multiplexador;
• Pads "bacanas" - Existem muitas ideias legais na construção de pads para e-drums. Uma delas é transformar um pandeiro em caixa, seja por conta do rebote da pele ou para detecção da batida no aro (Dual Zone).

    Eu utilizei como referência:

• Código, diagrama eletrônico e softwares para ler as mensagens MIDI da serial do Arduíno (hairless) e a criação de uma interface MIDI de loopback (LoopBE) para utilizar em software VST : http://arduinodrum.wordpress.com/download/
• Ideias sobre a montagem, ligação, pads e etc : Canal do Youtube do Filipe Santos( https://www.youtube.com/user/sobreviventeFCC) e o grupo do Facebook Drum DIY (https://www.facebook.com/groups/453458484705644/)
• Utilização do Multiplexador : http://playground.arduino.cc/learning/4051
• Mapeamento das notas MIDI de bateria : http://computermusicresource.com/GM.Percussion.KeyMap.html
• Sites de compra: www.soldafria.com.br , www.dx.com e www.aliexpress.com

   O material utilizado até o momento para montar o protótipo:

• Pads feitos de EVA de um tatame velho;
• Piezos 27mm ;
• Diodo Zener 5V1 1W
• Resistor de 1M Carbono 5% 1/4W
• Multiplexador HC4851n
• Breadboard, cabos, ferramentas, computador e etc.
• Software Ezdrummer 2, que transforma as mensagens MIDIS em som

Ligação do Protótipo

Ligação do Multiplexador

Ligação Arduíno

Plataforma de Testes

O código utilizado para ligação de 4 pads. Neste caso só estou lendo o Pino analógico 0 (um pad qualquer) e o 1 (Ligado no Multiplexador). No Mux, estou lendo aos três primeiros pinos (0,1 e 2). É importante não percorrer todos os pinos se não estiverem sendo utilizados pois geram notas fantasmas.

    Uma amostra do estágio atual pode ser conferida neste vídeo :

Falta muito ajuste, principalmente na sensibilidade dos pads que estão falhando.... O positivo é que já está saindo som! :D

Câmeras de Vigilância IP Wireless com MiniPC (Cubieboard, Foscam/Wanscam, Linux e Zoneminder)

    Descreve-se neste post a implementação de um sistema de câmeras de vigilância (CFTV) IP Wireless(IEEE 802.11x), da masca Foscam e Wanscam, tendo como DVR um miniPC ARM (cubieboard) rodando Linux e o aplicativo Zoneminder. Existem muitos tutoriais explicando o funcionamento destes itens, este post é um agregador com algumas informações pontuais.
    As premissas deste projeto eram as seguintes:

• Utilização de câmneras wireless e IP. A preocupação seria somente com a parte elétrica.
• Um DVR pequeno para ser escondido/camuflado em algum local. Existem muitos casos em que em um arrombamento/roubo/assalto os meliantes acabam levando embora os equipamentos de vigilância também.
• O DVR deveria ter detecção de movimento e ser acessível pela Internet.

    Foram utilizados os seguintes componentes:

• Cubieboard : Primeira versão, com processador A10. Cogitei a utilização do Raspberry PI, mas o Cubie tem um hardware mais potente. Adquirido AQUI.
• Micro SD de 32GB: É o disco de armazenamento para as imagens do monitoramento;

• Câmera IP Wireless Indoor Foscam FI8918w : Adquirida AQUI;

• Câmera IP Wireless Outdoor Wanscam JW0006: Adquirida AQUI;

• O restante é o que geralmente já se tem: Access-Point/Roteador Wireless, ferramentas para fixação e etc.

    Com os componentes em mãos, as câmeras receberam as configurações de usuário, para utilização do zoneminder, e rede. (Referência de configuração da câmera Foscam http://www.youtube.com/watch?v=hyhmFmKB5Hs ). Após, foram fixadas nos locais desejados para o monitoramento. Nesta etapa é importante verificar a questão do sinal wifi e da possível interferência de canais de outras redes wifi. Foi feito uso do aplicativo para Android Wifi Analyzer para escolha do melhor canal e medição da potência do sinal.

    Com as câmeras funcionando, parte-se para a configuração do DVR que será o Cubieboard com Ubuntu Linux 12.04 rodando Zoneminder. A primeira etapa é a instalação do Ubuntu na memória NAND do Cubie Board, o cartão SD card será utilizado somente para as imagens gravadas pelo Zoneminder. O procedimento de instalação é este : http://www.youtube.com/watch?v=v_MC_szPZmU e os procedimentos de pós-instalação são este http://linux-sunxi.org/Install_Ubuntu_Linux_for_Cubieboard e este http://blogzs1jen.dyndns.org:83/cubieboard-ubuntu-lenario-initial-configuration/ . 

    A instalação do Zoneminder pode ser feita desta forma http://www.zoneminder.com/wiki/index.php/Ubuntu_Server_12.04_64-bit_with_Zoneminder_1.25.0_the_easy_way. 

    A essa altura, O Zoneminder já esta acessível e pronto para ser configurado. A primeira configuração é dos monitores (câmeras). Toda a documentação do Zoneminder pode ser encontrada aqui http://www.zoneminder.com/wiki/index.php/Contents . Tanto a Foscam como a Wanscam (que é um clone da Foscam) tem suas configurações descritas na documentação do Zoneminder, na seção Hardware Compatibility List .

 

   

    Agora as situações específicas desta implementação:

• Redirecionamento das imagens para o Sdcard:
  
      Formatado o SDCARD (que neste caso apareceu como mmcblk0p1) em ext4, adicionada uma entrada na fstab (/dev/mmcblk0p1 /media/SD ext4 rw 0 0), criada uma pasta zoneminder (e as subpastas events e images) e  criado links para as pastas events e images do "/var/cache/zoneminder". É necessário parar o Zoneminder para executar isso.
  
  linaro@cubieboard:/var/cache/zoneminder$ ls -lhtotal 1.0Klrwxrwxrwx 1 root root   28 Sep 14 16:50 events -> /media/SD/zoneminder/events/lrwxrwxrwx 1 root root   28 Sep 14 16:50 images -> /media/SD/zoneminder/images/drwxr-xr-x 2 root root 1.0K Jun  2  2012 temp
  
• Problema "Share Data Size Conflict":
  
      Resolvido utilizando este post: http://lachlanmiskin.com/blog/2012/06/24/zoneminder-shared-data-size-conflict-in-shared_data-for-monitor/
  
• Alto consumo de CPU:
  
      Foi necessário diminuir a taxa máxima de fps para que reduzir a taxa de utilização da CPU do Cubieboard.
  
  
  
  Na configuração "default" (sem limite de fps) com os dois monitores em funcionamento o consumo de CPU ficava em 100% direto. Ajustando para 10fps o consumo ficou em média 80%.
  
  
  
  Acredita-se que  utilizando a versão 2 do Cubieboard (que é Dual Core) possa ajudar nisto. O Zoneminder trabalha com scripts Perl, logo não existe nenhuma possibilidade de melhoria da perfomance realizando uma compilação. Uma outra alternativa é utilizar a aplicação Motion no lugar do Zoneminder, que parece resolver este problema de utilização de CPU, embora ela seja bem simples não tendo recursos de interface web amigável.
  
• Utilização pelo Celular:
  
  Feita a configuração de Port Redirection (específica em cada caso, dependendo da topologia de rede da residência) e o uso de serviços de DDNS (como o No-IP) é possível acessar a interface web do ZoneMinder pela Internet. Embora seja possível ser utilizada por celulares desa forma, existem vários aplicativos nativos que acessam o Zoneminder. Um deles é bastante interessante, o Zmview (https://play.google.com/store/apps/details?id=com.html5clouds.zmview&hl=pt_BR). Permitindo de forma rápida acessar os monitores (Câmeras) em tempo real ou os eventos gravados.
  
• Configurando o NO-IP
  
  A configuração do NO-IP para o Ubuntu 12.04 pode ser encontrada aqui http://www.howtoforge.com/how-to-install-no-ip2-on-ubuntu-12.04-lts-in-order-to-host-servers-on-a-dynamic-ip-address

Processando e-mails: Uma abordagem simplificada do GTD para e-mails

      Este não é um post tão técnico, mas não conheço uma pessoa que trate de assuntos técnicos que não tenha que trabalhar com e-mails. Acredito que todos tenham enfrentado uma situação de se sentir desorganizado ou não eficiente. Apresento uma método que eu utilizo e, pra mim, se tornou vital!

      Existia uma época que eu imaginava que ter vários filtros no meu cliente de e-mail (seja um cliente web ou desktop) era sinônimo de ser organizado. Tinha várias pastas, tudo divido por pessoas ou por grupos. Não vou negar que esta abordagem até funcionava, pelo menos enquanto a quantidade de mensagens ou de atividades que elas carregavam não eram volumosas.

     Uma vez que a quantidade de mensagens começaram a aumentar, a coisa começou a complicar. Era comum esquecer algo ou passar batida alguma mensagem importante. Fui atrás de uma metodologia de organização pessoal, assim conheci o GTD (Getting things done ) do David Allen por meio do livro "A arte de fazer acontecer". 

     O GTD é um método de gerenciamento de ações bastante completo. Ele foi concebido para que você gerencie toda sua vida : De projetos no trabalho até como/quando pagar conta de energia elétrica. 

    Uma das premissas do GTD é que você tem que manter sua cabeça "descarregada", você não pode confiar na sua mente para lembrar de tudo, pois uma hora ou outra ela falha. Existem casos piores, quando a sua mente "bipa" as coisas em momentos em que você não pode fazer absolutamente nada. Muitas vezes, naquela hora em que estamos pegando no sono, minha mente trazia atividades que eu tinha que realizar... mas não naquela hora. 

    Para que você mantenha sua cabeça "limpa" as suas pendências devem estar armazenadas em algum local e dentro de um processamento que você confie. Se você não confia na sua forma de organização, sua mente tentará fazer o trabalho de lembrar das suas pendências (e ela não é tão inteligente para este tipo de coisa). O objetivo deste post não é falar de todo o GTD, mas apresentar uma abordagem simplificada, baseada no mesmo, para o processamento de e-mails. Para os que quiserem saber mais, leiam o livro! :)

   Para a utilização deste método você precisa:

                      - Cliente de e-mail que suporte criação de pastas, rótulos ou marcadores;

                      - Um Calendário (seja físico ou virtual);

                      - Disciplina.

          

   O Fluxograma acima contém toda a lógica do processamento. Você não usará filtros, você realizará o trabalho de filtragem e processamento manualmente, pois fará parte da metodologia. Os "azuis" do fluxograma são as pastas/rótulos/marcadores que você criará dentro do seu cliente de e-mail.  

   Todos os seus e-mails devem chegar em um único ponto que é a caixa de entrada , você deve  processá-la periodicamente. O objetivo é sempre limpá-la, tudo tem que ser tratado e receber um destino. Se existe algo na caixa de entrada é porque está esperando a sua análise, nada deve ficar na caixa de entrada após a análise. O processo de processamento é simples e está explicado nas estruturas de decisão do fluxo. 

   A pasta referência receberá tudo que merece ser armazenado. Um assunto que já foi resolvido, um link interessante, algo que você irá precisar no futuro e etc. É um arquivo. Todos os clientes de e-mail que eu conheço (seja desktop ou web) tem recursos de busca, você utilizará este recurso na hora de buscar algo no seu "arquivo".

   No "Em espera" ficarão os e-mails que você repassou para alguém resolver e que precisa "monitorá-los" até receber a resposta. Uma vez que a pessoa responda este e-mail (que vai cair na Caixa de entrada novamente, lembre-se, não existem filtros) caso esteja resolvido ele irá para o referência.

   "Próximas ações" são as mensagens que você tem que realizar uma atividade. Será sua lista de tarefas com as mensagens que não puderam ser resolvidas de bate-pronto.

   Caso o e-mail seja de alguma reunião ou evento que tem data certa para ser realizado, você utilizará o calendário para marcar isto.

    Uma vez implementado o método, a rotina de processamento é basicamente esta:

                 - Verificar o calendário;

                 - Limpar a caixa de entrada, realizando o "processamento". Algumas mensagens serão resolvidas na hora, outras deletadas, delegadas (Em espera), agendadas (calendário) ou esperarão para um momento oportuno (Próximas ações);

              - Verificará as mensagens que já foram delegadas anteriormente (Em espera), para verificar se precisa realizar uma cobrança e etc;

                  - Trabalhará nas suas tarefas (pasta próximas ações);

    O grande ganho de implementar este método de gerenciamento é que fica claro e fácil de identificar as suas pendências (Próximas ações) e as pendências que você delegou (Em espera). O que não presta é descartado (Lixeira), o que servirá algum dia ou é um assunto resolvido é arquivado (referência).

    Você não irá mais abrir a pasta de e-mails do seu chefe e ficar buscando,lendo e pensando: "o que eu tenho mesmo que resolver? o que eu já resolvi ? cadê aquela coisa que ele acabo de me cobrar?" kkk! 

     O que você tem que fazer está em um local (Próximas ações e Calendário), o que alguém tem que fazer pra você também (Em Espera). O que já foi resolvido ou você pode precisar em algum momento está guardado (referência). É uma metodologia orientada à ações.

    Um detalhe técnico que ajuda muito é se o cliente de e-mail agrupa as mensagens relacionadas (mensagens que são resposta de uma outra mensagem, criando um thread). O Gmail (o cliente que eu utilizo) faz isso por padrão (sei que o outlook também tem este recurso). 

    Alguns links de implementações de GTD em clientes de e-mail :

        - Gmail

        - Outlook

        - Thunderbird

     

      

Medir performance, detectar gargalos ou comportamentos estranhos em estações de trabalho windows : PERFMON!

    Volta e meia surgem situações onde máquinas apresentam lentidão, comportamentos não esperados e dúvidas são levantadas com relação a o que exatamente está causando este tipo de anomalia. Problemas atribuídos à rede, link ou Internet pode na verdade ser um problema na estação de trabalho. 

    Para detectarmos com exatidão o que está acontecendo podemos recorrer a ferramenta nativa do windows: Performance (perfmon).

    Com ela podemos selecionar "contadores" , que são variáveis diversas do sistema: % de utilização processador, memória, quantidade de dados que trafegam na rede, % de uso de determinado processo e  etc etc etc. 

    Ela também tem o grande recurso de agendamento (logs de contadores) que pode ser configurado para coletar com certa periodicidade (amostra) dos dados dos contadores durante determinado tempo (Horas, dias, semanas) para que, posteriormente, seja feita uma análise do log que pode ser aberto em qualquer outro computador que tenha perfmon.

   Uma estratégia interessante: Configure e agende por um tempo determinado um "monitoramento" utilizando o perfmon em uma estação de trabalho onde existem reclamações (mas geralmente quando chegamos na estação o problema "já acabou").

    Mais detalhes sobre o perfmon:

http://support.microsoft.com/kb/248345/pt-br

http://machado2003.spaces.live.com/blog/cns!3035E0AB234CD5D9!2562.entry

http://www.computerperformance.co.uk/HealthCheck/index.htm

    Sugestão de alguns contadores:

http://adminfoo.net/2007/04/windows-perfmon-top-ten-counters.html 

http://www.m86security.com/kb/article.aspx?id=10527):

    

     Análise de gargalos:

     Utilização de processador: System\Process Queue Length - Deve ser menor que 10

     Utilização de memória: memory\Pages input/Sec  - Deve tender a 0.

     Utilização de disco: PhysicalDisk\Current Disk Queue Length\Dirveletter - Entre 2 e 3

     Utilização de rede : Network Interface\Output Queue Length\nicname - Em média 2 pacotes

     

     Contadores Gerais:

      Utilização de processador: Processor\% Processor Time\_Total

      Utilização de memória: Process\Working Set\_total

                                        memory\Available mBytes

      Utilização de disco: PhysicalDisk\Bytes/sec\_Total

      Utilização de rede : Network Interface\Bytes Total/Sec\nicname

    Contadores por processo:

    Process\Private Bytes - nomedoprocesso

    Process\% Processor Time - nomedoprocesso

Obs : Nas novas versões do windows (Vista, 7, 2008 server) o "performance" é chamado de "Medidor de desempenho", mas continua com a mesma funcionalidade. 

Teste de largura de banda e QOS: Jperf (Iperf)

   O Jperf é um front-end gráfico em Java para o iperf. É uma ferramenta livre para testar a largura de banda em rede TCP/IP, sua funcionalidade principal, mas também é possível realizar outros tipos de testes como Jitter, perda de pacotes e configurações de QOS. O Jperf (e o Iperf) tem versões para windows e linux e pode ser obtido aqui : http://code.google.com/p/xjperf/ . Ele não é "instalável", só é necessário que a máquina tenha o JRE.
   A saída do teste é textual (pela aba output) e gráfica, a duração e amostragem são configuráveis.

 
   Ela funciona no esquema  "cliente/servidor": Abre-se uma instância do Jperf em uma ponta do link alvo do teste, configura-se a porta e é iniciado como servidor. Do outro lado do link, fica no modo cliente em que o IP do servidor e a porta (existe uma série de outras opções opcionais para customização do teste) devem ser passados como parâmetros. É possível realizar o teste tanto com TCP como UDP (O cliente e o servidor devem estar configurados para utilizar o mesmo protocolo).

   Considerações importantes:

• O sentido do tráfego é do cliente para o servidor, é como se o lado servidor fosse realizar um download do cliente (o cliente que "empurra" os bits, o servidor só recebe e manda os acks). 
• Infelizmente não é possível configurar a porta origem no cliente o que não torna a ferramenta "perfeita" para um teste de QOS, mas ainda assim "dá pro gasto". Existe uma outra ferramenta mais robusta (mais complicada e mais feia) que consegue realizar isto, é o MGEN,  desenvolvido pela Marinda dos E.U.A  http://cs.itd.nrl.navy.mil/work/mgen/
• É possível abrir várias instâncias do Jperf para testes com vários fluxos em diferentes portas, tome cuidado com as portas para não bater com algum serviço que já esteja escutando na máquina.

   Um teste de QOS pode ser implementado da seguinte maneira:

1. Na ponta que será "servidora" é aberto 3 instâncias do Jperf, cada uma utilizando uma porta distinta que estejam configuradas com prioridades diferentes nos roteadores.
2. Na ponta cliente faça testes variados: ora utilize somente uma porta, depois ative outro fluxo da outra porta ou ainda mais de um fluxo na mesma porta (com a opção parallel streams). Será possível verificar se as políticas de QOS estão funcionando (lembre-se do sentido do tráfego).

   Segue um teste que realizei numa rede wireless N. Os nós (lado cliente e servidor) estavam "linkados" em 65Mbps, na prática não chega a 10Mbps (fica ocilando nos 9Mbps). O lado cliente estava configurado com dois fluxos (parallel strems), durante 600 segundos (Transmit) e a cada 5 segundos era exibida a throughput de cada fluxo e a soma (Report Interval)

      Para mais dicas sobre testes utilizando Jperf (e Iperf), visitem http://openmaniak.com/iperf.php

Alta Disponibilidade(HA): Mcafee Firewall Enterprise 8.2

   Esta postagem demonstra a instalação, utilizando máquinas virtuais, e configurações básicas de um cluster de alta disponibilidade utilizando o Mcafee Firewall Enterprise versão 8.2.

   O MFE tem como base o mesmo sistema operacional do PFsense (FreeBSD) com customizações que leva o nome de SecureOS.

   Este Firewall conta com todas as capacidades de um FreeBSD adicionando algumas funcionalidades interessantes como GTI , GeoIP, Smart Filter, conceito de zonas, interface gráfica e muito, muito mais (como fala a gravação do suporte Platinum da Mcafee kkk). Para quem estiver procurando um firewall, vale a pena conhecê-lo.

   A maior parte da administração rotineira é feita via Interface Gráfica (o software cliente admin console, for windows), embora também esteja disponível acesso SSH (com comandos dos "BSD likes" mais comandos específicos do SecureOS, existe um manual que discorre sobre eles).

   Tendo em mãos a ISO do firewall, pacote de instalação do Admin Console, Vmware Workstation e uma máquina que suporte a execução destes componentes, podemos começar a instalação.

• obs¹: O MFE requer uma licença, caso não seja inserida uma licença válida ele funciona por 30 dias, o que para fins de POC ou LAB é suficiente.
• obs²: Eu tenho acesso a estes softwares por trabalhar em um local que tem licenças MFE e acesso para download no site da Mcafee, caso não seja seu caso, entre em contato com um revendedor/parceiro Mcafee.
• obs³: O MFE tem um manual bem abrangente e a Mcafee tem uma base de conhecimento bacana. 

A estrutura que será configurada:

Topologia e endereçamento dos membros e do cluster

   As configurações de hardware mínimas das VMs para esta configuração de cluster. Lembrando que são necessárias duas máquinas:

   

Realize o boot com a .iso , caso seja uma máquina "limpa" ele realiza um "auto-instalador" e reinicia a máquina. O processo de instalação básica deve ser realizado nas duas máquinas.

Início

Auto Install

Instalação

Término da auto-instalação

 Após esta instalação preliminar ele reiniciará a máquina e pedirá as configurações. Existe uma forma de fornecer as configurações e licenças por meio de um pendrive, utilizando o software "quick start" que é instalado junto com o "admin console". Aqui será configurado manualmente:

Tela após a instalação preliminar

EULA

Aceitando EULA

Identificação para o licenciamento

   Após estas etapas, começa a configuração. Não iremos configurar o firewall para ser gerenciado por um Control Center (Outro produto para centralizar a gerência de um parque de MFEs), não iremos utilizar o modo bridge e, inicialmente, só terá regras que permitem a administração do firewall. Na configuração é requisitado o endereçamento da interface interna e externa, usuário, senha, dns, default gateway e servidor de e-mail. A última pergunta é sobre se a administração será realizada somente pela zona Interna.

   O conceito de Zonas é interessante: várias interfaces de rede podem participar de uma mesma zona e regras podem ser atribuídas por zonas. É um artifício para regras (ou ACLs) ou configurações que podem ser aplicadas para várias redes, evitando redundância.

Configurações

Configurações

Configurações

Revisão das configurações

Software instalado

   Com o software instalado, toda a configuração pode ser realizada via Admin Console. O procedimento é muito simples, basta adicionar um firewall (sua máquina deve estar na mesma rede da interface interna) e o IP. Será pedido o usuário e senha:

Primeiro acesso via Admin Console

Acesso via Admin Console

Janela da aceitação do certificado.

Acesso via Admin Console

Acesso via Admin Console

Dashboard

Configurações das interfaces de rede

IMPORTANTE - Liberando o ICMP echo na zona, se desejado

Configuração de interface de rede

Interfaces de rede

   A configuração das interfaces de rede é muito simples. É importante manter a consistência nos nomes das zonas, das interfaces de rede e do endereçamento nos firewalls que farão parte do cluster. Reserve uma interface de rede, zona e endereçamento para o heartbeat. Uma vez tudo pronto, é hora de partir para o wizard do cluster em uma das máquinas:

Configuração de cluster

Criação do Cluster

Tipos de cluster

   Os modos de funcionamento do cluster no MFE são divididos em duas famílias : Load-Sharing HA (que é a opção homônima) e Failover HA (Peer-to-peer HA ou Primary/Standby HA). O modo Load-Sharing distribue a carga entre os membros, logo os dois membros estarão trabalhando em conjunto, no modo Failover um trabalha e o outro fica em standby. A diferença do Peer-To-Peer para o Primary/Standby é que no segundo você define quem será o principal e ele sempre assumirá a carga caso esteja funcional, no primeiro irá depender do tempo de takeover para saber quem será o principal em um momento de falha. Será utilizada o modo Failover HA - Primary/Standby HA.

   Uma observação importantíssima: O modo Load-Sharing HA é extremamente dependente da solução de camada dois de rede (switching) e exige um cuidado e trabalho bem maior na implantação, por experiência própria tenha cuidado (seja com este produto ou com qualquer outro) quando a solução promover este tipo de funcionalidade (Não é todo switch que possibilita a configuração de Unicast-mirrored ou MAC Multicast e eu acho "feia e ignorante" a solução de Unicast-flooded).

   Após selecionado o modo do Cluster, aparecerá a tela de configuração dos IPs do Cluster, bem como a necessidade de ser configurada a zona de heartbeat (onde é realizado os testes de disponibilidade entre os membros):

Endereços compartilhados do cluster

Zona para o heartbeat

Revisão da configuração do cluster

   Depois da criação do cluster no primeiro membro, é preparada a configuração dos membros adicionais na seção "Pair Members". É indicado o nome, endereço, o tempo de takeover e uma chave de registro. Após isto, é necessário iniciar o wizard do cluster no segundo membro e escolher a opção "join existing cluster" e utilizar as informações previamente configuradas no primeiro membro :

Tela da configuração do cluster

Adicionando um membro do cluster

Término da preparação para o segundo membro

Adicionando um membro no cluster

Parâmetros previamente configurados no primeiro membro do cluster

    Depois destas etapas é só conectar no endereço internal do cluster para a administração. Eis um  cluster de Mcafee Enterprise Firewall com dois membros no modo failover HA Primary/Standby pronto pra guerra. 

Conectando no cluster

Dashboard do cluster