quarta-feira, 11 de julho de 2018

Política de Privacidade

Este Blog usa os seguintes serviços e parcerias que funcionam junto com a estrutura da página. Eventualmente alguns dados podem ser coletados, tanto em formulário, como em banners e elementos de página para redes sociais ou serviços de monetização.
  • Este site pode utilizar cookies e/ou web beacons quando um usuário tem acesso às páginas. Os cookies que podem ser utilizados associam-se (se for o caso) unicamente com o navegador de um determinado computador.
  • Os cookies que são utilizados neste site podem ser instalados pelo mesmo, os quais são originados dos distintos servidores operados por este, ou a partir dos servidores de terceiros que prestam serviços e instalam cookies e/ou web beacons (por exemplo, os cookies que são empregados para prover serviços de publicidade ou certos conteúdos através dos quais o usuário visualiza a publicidade ou conteúdos em tempo pré determinados). O usuário poderá pesquisar o disco rígido de seu computador conforme instruções do próprio navegador.
  • Usuário tem a possibilidade de configurar seu navegador para ser avisado, na tela do computador, sobre a recepção dos cookies e para impedir a sua instalação no disco rígido. As informações pertinentes a esta configuração estão disponíveis em instruções e manuais do próprio navegador.
Abaixo estou listando outros tipos de dados coletados por serviços de terceiros inseridos no Blog:
As informações desta Política de Privacidade podem ser alterado sem aviso prévio ou posterior.
Questões de Privacidade.

terça-feira, 22 de abril de 2014

Ldap no Centos

Isto foi um passo a passo rápido que eu fiz para instalar o ldap no Centos a administra-lo via PhpLdapAdmin. Não é o melhor tutorial da Web, mas foi o que deu certo na minha configuração de centos.

Passo a Passo
1- cp /usr/share/openldap-servers/DB_CONFIG.example /var/lib/ldap/DB_CONFIG
2- chown -R ldap:ldap /var/lib/ldap
3- cd /etc/openldap
4- cp /usr/share/openldap-servers/slapd.conf.obsolete /etc/openldap/sldap.conf (cria)
5- slappasswd
6- SALVAR A PORRA DA HASH {SSHA}JopQPk70EN/ij7tlpG8tsw+D9+s4JGfm
9- vim /etc/openldap/ldap.conf coloca a hash rootpw (configuração do arquivo)*

# enable server status monitoring (cn=monitor)
database monitor
access to *
by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read
by dn.exact="cn=Manager,dc=havarydc=com" read
by * none
#######################################################################
# database definitions
#######################################################################
database bdb
suffix "dc=havary,dc=com"
checkpoint 1024 15
rootdn "cn=Manager,dc=havary,dc=com"
# Cleartext passwords, especially for the rootdn, should
# be avoided. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
# rootpw secret
rootpw {SSHA}JopQPk70EN/ij7tlpG8tsw+D9+s4JGfm


10- cd /etc/openldap/slapd.d/
11- rm -rf *
12- slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d (criando os arquivos do ldap)
13- chown -R ldap:ldap /etc/openldap/
chown -R ldap:ldap /var/lib/ldap
14- service slapd restart
15- ldapsearch -x -b "dc=havary,dc=com"
16- criar a base ldapadd -x -D cn=Manager,dc=havary,dc=com -W -f empresa.ldif

# arquivo empresa.ldif
# inicio da estrutura (DIT)
dn: dc=havary,dc=com
objectClass: top
objectClass: dcObject
objectClass: organization
o: Empresa Ltda
dc: havary

#unidades
dn: ou=usuarios,dc=havary,dc=com
objectClass: top
objectClass: organizationalUnit
ou: usuarios
dn: ou=grupos,dc=havary,dc=com
objectClass: top
objectClass: organizationalUnit
ou: grupos


17- cp /usr/share/doc/phpldapadmin-1.2.3/config.php.example /etc/phpldapadmin/config.php
18- restart httpd restart
19- 127.0.0.1/url

Claro que isto esta bem simples e sem nenhuma explicação. Mas é para a minha documentação pessoal.
Aviso importante, salva a porra da HASH, eu perdi isso ai tive que começar do zero.
Agradecimentos especiais ao meu amigo Fabio Beato pela participação neste lab.

Ficou difícil de ler isso aqui, preciso melhorar esse blog depois.

Linux LVM

Acho que todo mundo já apanhou e aprendeu sobre LVM. Eu já apanhei muito. Hoje sempre faço um LVM nos servidores. Mesmo que eu não tenha planejado usa-lo no futuro. As vantagem são muitas. 
Abaixo é mais um tutorial pessoal de como de uma documentação de consulta rápida que eu uso para me orientar quando irei trabalhar com o LVM.

Preparar o disco com Fdisk
#sudo fdisk /dev/xvdf
comandos no fdisk n, t(8e), w (configurações dentro do fdisk)
#pvcreate /dev/disk1
#vgcreate vgdisk /dev/disk1
#vgchange -an (ativa todos os VG)
#lvcreate -L 30G vgdisk (crio um volume lógico com 30gigas)
#mkfs.ext4 -L nome_do_disco /dev/vg_name/lv_name

#vim /etc/fstab

/dev/vg_name/lv_name /mnt/nome_dir ext4 defaults 1 2

Extender um disco LVM

#pvresize -v /dev/xvdb (as vezes precisa)
#pvcreate /dev/xvdh1
#vgextend indice /dev/xvdh1
#lvextend -L+60.00G /dev/indice/lvol0
#resize2fs /dev/mapper/indice-lvol0



Montar um disco LVM de um servidor em outro servidor

#vgscan
#vgchange -ay vg-volume-xxx
#lvscan
#mount -t ext4 /dev/vg-volume-xxx/lvol0 /volume

Claro que isto não e uma documentação ou um tutorial. É algo mais prático para o meu dia a dia.

terça-feira, 21 de agosto de 2012

Amazon AWS Summit 2012 | Navigate the Cloud

AWS Summit

Bom, é um evento informativo a respeito do Amazon Web Serviçes, suas soluções, serviços, tecnologia e cultura. Além da possibilidade de exposição das soluções de parceiros para o AWS. 

O AWS Summit possibilitou a todos uma visão geral da nova "modalidade" de infraestrutura em TI, a computação nas nuvens. Mostrou casos onde a aplicabilidade desta solução viabilizou um negocio com um baixo TCO, alta flexibilidade de gerenciamento e possibilidade de crescimento dimensionado.

A abertura do Werner Vogels nos mostrou que o novo passo para uma TI moderna, segura e confiável está nas nuvens e os parceiros Amazon explicaram como o cloud os ajudou a solucionar problema de forma ágil e concreta e em alguns casos possibilitou até a criação de empresas.

Primeira foto do dia, um dos parceiro da Amazon a redhat.


 Um trecho de um documento da Intel, outro parceiro, sobre a crescente importância do cloud.


 Aqui começa o AWS 


A Amazon tem uma filosofia de redução do preço cobrado pelos seus serviços na media em que você vai utilizando cada vez mas. Ela até ensina como você pode otimizar seus gastos com o AWS. 


O funcionamento do serviço de rede do AWS 


Um slide sobre o funcionamento do serviço de storage da Amazon


Nosso amigo Werner Vogels da Amazon, de longe o melhor palestrante do evento. Muito carismático.


Um novo serviço que acaba de ser lançado pela Amazon nos USA, o Glacier. Diferente do S3, que é uma storage, o Glacier é um archive, sua principal função e armazenar dados pouco utilizados, ex. backups. O custo do Glacier é inferior se comparado com o S3, provavelmente pela diferença de desempenho na disponibilização de dados. Sendo assim os backups que hoje são guardados no S3 poderão ser guardado no Glacier, otimizando o gasto com os custo do armazenamento nas nuvens.


VPC - Um link entre seu datacenter físico e o datacenter na nuvem.



Uma palestra sobre como montar na Amazon um cenário a prova de falhas. Uma explicação de como melhor usar os recursos disponibilizados por ela.


Nosso palestrante que fala muito rápido em inglês. Ryan Holland. 

O que eu pude entender bem da palestra do Ryan é o conceito de Monitorar, Identificar e Automatizar

Numa aplicação hospedada no AWS ou um servidor hospedado na Amazon, podemos Monitorar o seu comportamento, monitorar a utilização do recurso. A importância do Monitoramento é a identificação de padrões do comportamento da aplicação/servidor. Assim conseguiremos mensurar uma necessidade de aumento de um recurso quando a aplicação estiver sobre pico de uso, protegendo-a de uma lentidão ou do congelamento do servidor, evitando uma falha. Conseguimos também diminuir esse recurso quando a aplicação estiver com seu consumo de recursos normalizados ou fora do pico de utilização. Com a união do monitoramento e da identificação poderemos Automatizar o processo de adequação de recursos para as instâncias e assim deixar nossos sistemas e aplicações completamente a prova de falhas. 



Esse slide e os dois próximos eu achei um pouco estranho. O primeiro fala sobre uma topologia que não esta de acordo com os padrões de tolerância a falhas. Dois slides abaixo ele mostra como deveria ser uma topologia de tolerância a falhas na Amazon. 

Bom minha opinião quanto a isto é que a Amazon tem 3 data center em são paulo, para que esta região não fique offiline. Então qual o motivo que eu vou usar uma solução de redundância da Amazon? Para gastar mais dinheiro. 

Concordo com o uso do Elastic IP apontado para duas maquinas igual com o mesmo sistema no caso de que você pode executar uma atualização em uma das maquinas, retirar ela do Elastic, e testar uma nova versão de software, antes de decidir se vai subir em produção ou não. Isso na verdade é um procedimento de homologação de produto que deveria ser o padrão sempre. 

Mas criar um backup do seu site inteiro na Amazon para caso uma das regiões apresente problemas é  muita loucura. Se a região de são paulo parar (lembrando dos 3 data centers) o menor dos meus problemas será os servidores da minha empresa. Eu imagino algo como no Duro de Matar 4 quando a cidade inteira esta destruída, ou o novo modern warefare 4, ou o Bane querendo destruir São Paulo, porque Gothan ele não ficou satisfeito com a destruição que ele fez. Se até a Stark Tower parou quando a cidade foi destruída......






Aqui são as diretrizes que devemos seguir para termos um sistema totalmente a prova de falhas.





Aqui começa a melhor palestra do dia. Tanto pelo conteúdo quanto pelo palestrante. O Jinesh Varia, um indiano, é muito bom palestrante e fala muito bem inglês. Quando eu vi o nome dele, eu pensei que seria muito difícil de entender a palestra. Mas até que não. Em alguns momentos ele falou muito rápido,  mas não atrapalhou muito o entendimento do conteúdo.




A ideia principal desta palestra realmente é bem representada pela foto abaixo. Você usa e paga somente o que precisa. Quando você quer sentar em uma praça você não precisa pagar por todo o assento, somente pela parte que você irá utilizar. Caso chegue a sua namorada, você contrata ondemand  uma outra parte de assento, e paga extra pelo tempo que você ficarem sentados juntos. Quando você for embora não esquece de desconfigurar o assento adicional. :-p



Aqui ele mostra a configuração de uma empresa onde podemos verificar que ela possui servidores em load balance para aguentar o alto processamento ou trafego de arquivos. Imagina uma aplicação pesada rodando. Agora olhe o próximo slide.


Essa aplicação não terá um alto processamento ou trafego de utilização quando seus clientes estiverem dormindo correto? Então pra que deus você vai deixar suas maquinas ligadas. O Jinesh sugere a você desligar uma parte sua infra lógica, Assim você tem uma economia, pois você somente deve ligar os outros servidores em momentos de picos de processamento ou nos horários onde é uma maior utilização. No caso deste exemplo, as maquinas adicionais ficam ligadas apenas no período comercial. nas 12h restante apenas uma parte do ambiente esta ligada, somente para que a aplicação não fique offiline.


Aqui tem um pouco mais de teoria sobre ligar/desligar as máquinas em horários. O auto scaling ele deverá ser configurado para possibilitar esse processo de ligar e desligar conforme um horário. 
Alem da configuração do horário, podemos criar uma policy, e configurá-lá para detectar por exemplo a utilização de CPU. Caso essa utilização atinja 60% a policy pode ligar a máquina secundária automaticamente. 


Aqui um resumo das Best Practices sobre o auto scaling


Aqui uma recomendação de uma policy de auto scaling de CPU