Instale ZNC IRC Bouncer on AWS Linux

08 Dec 2017

Se você quer instalar ZNC IRC Bouncer você vai precisar do CMake, porém a versão do CMake do AWS Linux é desatualizada. (Atualize seu cmake para 3.x)[http://www.matbra.com/2017/12/07/install-cmake-on-aws-linux.html]

Agora você precisa do git para clonar o código fonte do ZNC e também o openssl-devel para ter suporte ssl.

# yum install git openssl-devel

Clone o código fonte

$ git clone https://github.com/znc/znc.git

Entre na pasta

$ cd znc

Inicializa os submodulos

$ git submodule update --init --recursive

Instale

$ cmake . 
$ make
# make install (run this as root #)

Configure-o:

$ znc --makeconf

Atenciosamente, Matheus

Comment

Instalando Cmake 3 no AWS Linux

07 Dec 2017

Se você está tentando compilar algo utilizando o CMake e tem o erro: “CMake 3.1 or higher is required. You are running version 2.8.12.2”

Você pode manualmente instalar a versão mais recente do CMake, para fazer isso. Eu removi o CMake existente.

# yum remove cmake

Teste se ele realmente foi removido

$ cmake

-bash: /usr/bin/cmake: No such file or directory

Instale G++

# yum install gcc-c++

Baixe a ultima versão do: Cmake Download

$ wget https://cmake.org/files/v3.10/cmake-3.10.0.tar.gz

Extraia:

$ tar -xvzf cmake-3.10.0.tar.gz

Entre na pasta

$ cd cmake-3.10.0

Instale com

# ./bootstrap
# make
# make install

Agora você deve ter o cmake instalado /usr/local/bin/cmake

Abraços, Matheus

Comment

Loopback migrando seus models com o postgresql

08 Jan 2017

Eu estou brincando com o Loopback, um framework javascript. Inicialmente eu só estava criando modelos e utilizando o explorer para verificar os resultados do mesmo, porém agora eu atingi um ponto que preciso persistir os dados.

Eu não consegui encontrar como manter meu banco de dados e meus modelos sincronizados facilmente, não tenho certeza se eu que não estou tão familiar com o Loopback ainda, ou se a documentação esta realmente um pouco confusa.

Então para criar um script que mantenha seus modelos sincronizados você pode criar um arquivo na pasta bin e nomea-lo autoupdate.js e adicionar o seguinte:

var path = require('path');

var app = require(path.resolve(__dirname, '../server/server'));
var ds = app.datasources.db;
ds.autoupdate(function(err) {
  if (err) throw err;
  ds.disconnect();
});

O código é bem simples, ele vai importar seu app do server.js, adicionar o datasource e rodar o comando autoupdate. Você poderia usar automigrate mas este limpa o seu database todas as vezes, então se você quer manter seus dados, essa não é a maneira apropriada.

Eu acredito que isso vai funcionar para outros bancos de dados, como MySQL. Se não funcionar, me avise, eu posso tentar ajudar.

Matheus

PS: Ele não vai fazer uma gerencia como o Django faz pra você, então as vezes você pode cair em estados indesejáveis, acredito que o ideal seria utilizar loopback com NoSQL

Comment

Django Storages com Boto3 e Metadados adicionais somente para as Medias

29 Dec 2016

Eu tenho um projeto pessoal o qual estou usando Django com django-storages para enviar meus arquivos estáticos e medias para a Amazon S3, já que as minhas medias possuem UUID e não são editáveis eu gostaria de ter um tempo de expiração maior para elas, assim eu poderia salvar transferência porém eu não gostaria de ter essa cache maior para os arquivos estáticos que são atualizados com mais frequência.

Maioria dos conteúdos que encontrei na internet se referiam a AWS_HEADERS porém o mesmo não funcionou para mim. Parece que o mesmo só funciona para o boto (não para o boto3) e depois de olhar o código do boto3 eu descobri o AWS_S3_OBJECT_PARAMETERS o qual funciona para o boto3, mas esta é uma configuração global então eu precisei extender a classe S3Boto3Storage.

Então o código que resolveu meu problema foi:

class MediaRootS3Boto3Storage(S3Boto3Storage):
    location = 'media'
    object_parameters = {
        'CacheControl': 'max-age=604800'
    }

Se você está usando o boto (não o boto3) e gostaria de ter meta dados especiais somente para a sua classe Media, você pode usar:

class MediaRootS3Boto3Storage(S3BotoStorage):
    location = 'media'
    headers = {
        'CacheControl': 'max-age=604800'
    }

Você também vai precisar atualizar a sua configuração do django-storages, preste atenção ao nome da classe, no boto 3 é S3Boto3Storage porém no boto, o mesmo não possui o 3 depois da palavra Boto

DEFAULT_FILE_STORAGE = 'package.module.MediaRootS3Boto3Storage'

Uma dica simples, porém pode salvar um pouco do seu tempo.

Matheus

Comment

Redirecionar acessos para um servidor Wordpress secundário usando Nginx

22 Dec 2016

Alguns de vocês provavelmente acompanhou, mas recentemente eu decidi atualizar meu antigo wordpress blog do PHP4~5 para um mais recente. Deixando meu host compartilhado e indo para o heroku e posteriormente para Amazon EC2.

Eu precisava decidir se eu manteria o Wordpress ou se eu mudaria para uma tecnologia diferente, como Jekyll? Ou o que? Eu pensei bastante sobre isso e no fim eu decidi utilizar Jekyll, por que? Para ser sincero, usando algo mais novo/recente me motiva a estudar e fuçar mais a fundo para conseguir as coisas rodando.

Depois que decidi que usaria o Jekyll, eu precisava pensar sobre meu dominio, eu queria manter meu blog antigo rodando como histórico mas também gostaria de fazer redirecionamento correto para não perder meus pontos de SEO por exemplo, então como manter 2 blogs funcionando de uma maneira inteligente sem quebrar os links antigos?

Eu pensei que o ideal seria algo que tentasse acessar o novo site e caso não encontrasse, deveria redirecionar para o blog antigo rodando Wordpress, mas como atingir isso somente quando a página não fosse encontrada e de uma maneira boa para SEO (utilizando 301 para os redirects)?

Depois de algum tempo brincando e lendo a documentação do nginx eu achei uma maneira de rodar um servidor com um proxy e caso o acesso falhe, interceptar o mesmo e redirecionar para outro servidor do nginx.

Então para fazer isso eu tenho um arquivo de configuração do nginx com multiplas configurações, a primeira delas possui a configuração do Wordpress, esse servidor é bem simples e somente trata acessos de páginas PHP com o PHP FPM basicamente usando um subdomínio.

server {
   listen 80;
   server_name wordpress.matbra.com;

    location / {
        root   /var/www/wordpress/live;
        index  index.php index.html index.htm;
        try_files $uri $uri/ /index.php?$uri$args;
    }

    location ~ \.php$ {
        root /var/www/wordpress/live;
        fastcgi_pass   unix:/var/run/php-fpm/php-fpm.sock;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        include        fastcgi_params;
    }
}

Compilando seu site em Jekyll depois do git push

12 Dec 2016

Se você quer compilar (buildar) o seu blog no seu próprio servidor depois de um git push, você pode usar os git hooks. Para fazer isso, você pode simplesmente extender a minha dica Deploy depois de push para também compilar o seu Jekyll como ambiente de produção. Para fazer isso basta adicionar o código abaixo depois do rm -rf

	cd $LIVE_PATH
	bundle install
	JEKYLL_ENV=production jekyll build

Matheus

Comment

Forçar www no endereço do seu Jekyll usando Javascript

11 Dec 2016

Eu queria fazer meu site ter sempre a mesma url, com o prefixo www como meu Jekyll não possui um back-end eu não podia fazer no servidor, portanto eu precisava utilizar Javascript ou meta tags. Algumas pessoas comentam que o buscador do Google considera tags meta refresh como redirects (301/302) então essa solução seria a mais adequada.

Teimoso do jeito que sou, decidi utilizar Javascript. Se você desejar fazer com que o seu blog tenha esse mesmo comportamento, utilize o seguinte código:

<script>
if (window.location.hostname.indexOf("www") != 0) {
	window.location = window.location.protocol + "//www." + window.location.hostname + window.location.pathname;
}
</script>

Eu criei um arquivo _include/force_www.html e estou usando a variável jekyll.environment para incluir essa paret do template e ter esse comportamento somente no ambiente de produção.

Matheus

Comment

Definindo variáveis de ambiente para o PHP-FPM

10 Dec 2016

Após instalar o nginx e o PHP, eu queria passar variáveis de ambiente para o PHP 7 para que eu não tivesse que salvar as configurações para o meu repositório.

Quando você utiliza variáveis de ambiente o ideal é defini-las sem deixa-las salvas, porém nesse caso eu salvei as mesmas.

Se você deseja adicionar variáveis de ambiente para o seu PHP-FPM, você pode editar /etc/php-fpm.d/www.conf (Estou fazendo isso no Amazon Linux e PHP 7.0)

Existe uma configuração no PHP-FPM, clear_env = no esta variável define se o PHP vai receber um ambiente limpo ou não. Eu deixei a mesma habilitada (o valor padrão é habilitado) mas adicionei as minhas variáveis de ambiente:

env[WP_SECURE_AUTH_KEY] = "valor1"
env[WP_NONCE_KEY] = "valor2"

Depois disso eu reiniciei o nginx e o PHP-FPM:

sudo service nginx restart
sudo service php-fpm restart

Matheus

Comment

Deploy depois de dar push com o seu git

09 Dec 2016

Eu expliquei como enviar seu código para o seu próprio servidor e depois disso você talvez queira executar algumas ações específicas, no meu caso eu gostaria que meu blog fosse atualizado quando eu enviasse uma nova versão para o git então eu usei um `post-receive hook.

Este script vai manter as 3 últimas versões do seu código, então se algo der errado, você pode fazer rollback mudando o link. Para fazer isso o script utiliza a variável DEPLOY_PATH e cria uma nova pasta sources nela, a qual vai ter as versões do seu site. A versão ativa é basicamente um link simbolico (symlink) da pasta live para a pasta sources

Variáveis:

REPO_PATH = Caminho para o seu repositório local
DEPLOY_PATH = Caminho para a pasta de release
DEPLOY_BRANCH = Branch que você quer lançar

#!/bin/bash
REPO_PATH=/home/someuser/test.git
DEPLOY_PATH=/var/www/
DEPLOY_BRANCH="master"

echo "REPO_PATH=$REPO_PATH"
echo "DEPLOY_PATH=$DEPLOY_PATH"

while read oldrev newrev refname
do
    branch=$(git rev-parse --symbolic --abbrev-ref $refname)
    if [ $DEPLOY_BRANCH == "$branch" ]; then
        TIMESTAMP=$(date +%Y%m%d%H%M%S)
        VERSION_PATH=$DEPLOY_PATH/sources/$TIMESTAMP
        LIVE_PATH=$DEPLOY_PATH/live
        echo "TIMESTAMP=$TIMESTAMP"
        echo "VERSION_PATH=$VERSION_PATH"
        echo "LIVE_PATH=$LIVE_PATH"

        mkdir -p $VERSION_PATH
        mkdir -p $VERSION_PATH/sources

        git --work-tree=$VERSION_PATH --git-dir=$REPO_PATH checkout -f $DEPLOY_BRANCH
        # Remove git files
        rm -rf $VERSION_PATH.git
        rm -rf $LIVE_PATH
        ln -s $VERSION_PATH $LIVE_PATH


        # Delete old folder keeping the 3 most recent ones, which aren't the current live one, / (root, security measure, different from your source folder)
        rm -rf $(ls -1dt $(find -L $DEPLOY_PATH/sources/ -maxdepth 1 -type d ! -samefile / ! -samefile $DEPLOY_PATH/sources/ ! -samefile $LIVE_PATH -print) | tail -n+3)
    fi
done

Se você ainda tiver alguma questão me avise, Matheus

Comment

Enviando seus códigos para o seu próprio git

08 Dec 2016

Eu estou mudando a minha infraestrutura como vocês devem ter percebido, neste momento eu gostaria de enviar meus códigos para o meu próprio servidor para poder fazer deploy com um simples git push my_server branch.

Então se você quer o mesmo tipo de comportamento você precisa conectar a sua máquina que vai hostear seu git com ssh e executar:

$ mkdir test.git
$ cd git
$ git --bare init

Você vai precisar saber o caminho completo para a pasta recém criada. Para verificar o diretório que você se encontra utilize pwd. Voltando a sua máquina local, adicione o seu servidor como uma origin no seu git.

git remote add my_server ssh://user@ip:/replace/with/pwd/test.git

Após isso você pode enviar os códigos do seu repositório utilizando git push my_server branch.

Matheus

Comment

Matheus Bratfisch Cogito ergo sum