Instalação e configuração de servidor de mídia com Raspberry pi 2: instalação do Kodi (parte 3 de 3)

Para instalar o kodi no raspberry:

pacman -S kodi-rbp

Escolher o libglvnd como provider do libgl. O pacote é o customizado para o Arch-ARM, por isso não é o pacote padrão que seria o kodi.

Instalação e configuração de servidor de mídia com Raspberry pi 2: instalação do Deluge (parte 2 de 3)

Continando a série de posts sobre a configuração do raspberry pi 2, eu faço a configuração completa do Deluge (cliente de torrent) para rodar como um serviço do sistema e ser usado remotamente por interface web.
Pra instalar:

pacman -S deluge python2-mako python2-service-identity

O pacote 'python2-mako' é necessário para a interface web funcionar corretamente.
Pegar o nome da dependência da montagem no systemd para que o serviço do deluge só rode quando o hd_externo (onde eu estou salvando os torrents) estiver disponível:

systemctl -t mount | grep -E '/mnt/hd_externo'

No meu caso é 'mnt-hd_externo.mount'.

Depois é necessário mexer no arquivo de serviço principal, que na minha instalação fica em /mnt/mp/deluged.service:

[Unit]
Description=Deluge Daemon
After=network.target mnt-hd_externo.mount
Requires=mnt-hd_externo.mount
BindsTo=mnt-hd_externo.mount
[Service]
User=deluge
ExecStart=/usr/bin/deluged -d -P /srv/deluge/.config/deluge/deluged.pid -l /var/log/deluge/daemon.log -L warning
UMask=0002
[Install]
WantedBy=multi-user.target

E também é necessário mexer no arquivo do serviço de interface web (/usr/lib/systemd/system/deluge-web.service):

[Unit]
Description=Deluge WebUI
After=deluged.service
[Service]
User=deluge
ExecStart=/usr/bin/deluge-web --ssl -l /var/log/deluge/web.log -L warning
[Install]
WantedBy=multi-user.target

É possível confirmar a localização dos arquivos de serviço com:

pacman -Ql deluge | grep -E 'service$'

Criar a pasta, arquivo de log com permissões seguras:

mkdir -p /var/log/deluge
chown -R deluge:deluge /var/log/deluge
chmod -R 750 /var/log/deluge

Evitar a criação de arquivos gigantes de log com o recurso de rotação de log: criar um arquivo /etc/logrotate.d/deluge com o conteúdo

/var/log/deluge/*.log {
        rotate 4
        weekly
        missingok
        notifempty
        compress
        delaycompress
        sharedscripts
        postrotate
                systemctl restart deluged >/dev/null 2>&1 || true
                systemctl restart deluge-web >/dev/null 2>&1 || true
        endscript
}

Criar um usuário para conectar remotamente no serviço do Deluge:

echo 'usuario:senha:10' > /srv/deluge/.config/delug/auth

Mexer nas chaves de configuração do /srv/deluge/.config/deluge/core.conf:

"move_completed_path": "/srv/deluge/completed",

"ignore_limits_on_local_network": true,

"allow_remote": true,

"download_location": "/srv/deluge/downloading",

"torrentfiles_location": "/srv/deluge/torrents",

"autoadd_location": "/srv/deluge/autoadd_torrents",

Habilitar o serviço:

systemctl enable deluged

systemctl enable deluge-web 

systemctl start deluged deluge-web

E o cliente para Android que eu estou usando (que é compatível com o Deluge, lógico) é o Transdrone

Link para a primeira parte do tutorial: instalação e configuração do Archlinux-ARM

Link para a terceira parte do tutorial: instalação do Kodi 

Referências:

1 Archlinux wiki: Deluge

2 Guia do usuário do Deluge: Scripts do SystemD

3 Guia do usuário do Deluge: Configuração do cliente magro

Instalação e configuração de servidor de mídia com Raspberry pi 2: instalação do Archlinux-ARM (parte 1 de 3)

Como o Manjaro no Arm está sendo descontinuado estou migrando minha máquina de torrent, digo, meu servidor de mídia :-), um Raspberry pi 2, para o Arch Linux ARM ao mesmo tempo que escrevo este post, vou me arriscar um pouco com os nada confiáveis repositórios do Archlinux, não vou entrar em detalhes, mas em resumo minha última experiência com o Arch no meu note não foi lá muito legal: toda a atualização eu já sabia que a máquina ia dar algum problema depois....

Vamos lá:

Imagem baixada e gravada seguindo esse tutorial
Depois do primeiro boot (fiz por ssh, então não sei como vai ficar o tty), fazer tudo como root (não custa lembrar):

Layous de teclado disponíveis:

find /usr/share/kbd/keymaps/ -type f -name \*.map.gz | less

Aplicando o novo layout à sessão atual:

loadkeys

Tornar persistente:

echo 'KEYMAP=br-abnt2' > /etc/vconsole.conf

Fontes de console:

find /usr/share/kbd/consolefonts/ -type f | less

Aplicar uma fonte à sessão atual:

setfont

Descomente o seu locale em: /etc/locale.gen (ctrl+w para procurar no nano)

nano /etc/locale.gen

Gerar o locale selecionado:

locale-gen

Criar o /etc/locale.conf com o idioma desejado e o charset padrão:

echo 'LANG=en_US.UTF-8' > /etc/locale.conf

Data hora atual:

date '+%F %T'

Listar fusos horários disponíveis

timedatectl list-timezones

Mudar o fuso horário:

timedatectl set-timezone

Pega a data/hora da rede:

timedatectl set-ntp true

Mudar o nome do host:

echo 'raspberry' > /etc/hostname

Colocar a entrada também no /etc/hosts (recomendável):

echo '127.0.1.1 raspberry.localdomain raspberry' > /etc/hosts

Não esquecer de mudar a senha do root:

passwd

Atualizar todos os pacotes:

pacman -Syu

Instalar os pacotes:

pacman -S zsh sudo tmux vim

Criar grupo 'sudo'

groupadd sudo

Liberar o acesso dos usuários do grupo sudo via comando 'sudo':

visudo

E adicionar ao final do arquivo:

%sudo ALL=(ALL) ALL

Listar todos os grupos com id's:

cat /etc/group

Criar um usuário não-administrador:

useradd --create-home --gid users --groups sudo -s /bin/zsh rmonico

Mudar a senha do novo usuário:

passwd rmonico

pacman -S deluge

# Para poder usar o alsamixer com kernel 4.4+

echo dtparam=audio=on >> /boot/config.txt

# Rebootar a máquina e entrar com o novo usuário criado

# Remover usuário alarm

userdel --remove alarm

# --remove apaga a home do usuário

# TODO: testar o kodi e o deluge

# tigervnc com xfce:

pacman -S xorg-server
pacman -S xfce4 # Opcional: escolher todos os pacotes que ele oferecer
pacman -S tigervnc

# Montando um hd externo conectado no roteador na inicialização:
# Adicionar ao /etc/fstab:

//router/volume1 /mnt/hd_externo cifs username=admin,password=sua_senha_aqui,nofail 0 2

# Em caso de problemas ver [6]

Fiz a configuração do deluge (cliente de torrent) em post separado

Link para a segunda parte do tutorial: configuração do Deluge
Link para a terceira parte do tutorial: instalação do Kodi

Efeito Pirula: fontes, mesmo quando não é necessário:

1 Guia de instalação do Archlinux (para desktop)
2 Instalação do Archlinux ARM no Raspberry PI 2 (informações adicionais)
3 Guia de instalação do Archlinux (recomendações gerais)
4 Archlinux Wiki: Kodi
5 Archlinux Wiki: gestão de usuários
6 Archlinux Wiki: Samba

Todas as dicas adaptadas e testadas no meu raspberry pi 2

Criando arquivos .gitignore

Geração automática de arquivos .gitignore:

http://gitignore.io

Só informar as tecnologias que o seu projeto usa e clicar no 'Generate' (útil?)

Update 26/mar/2017:
Criar atalho no git:

git config --global alias.ignore '!gi() { curl -L -s https://www.gitignore.io/api/$@ ;}; gi'

Chama com: git ignore Lista de tecnologias

Fonte: https://www.gitignore.io/docs

Versionando meu currículo

Este post é sobre como eu mantenho várias versões do meu currículo em paralelo, se você quiser saber apenas o como eu faço e não o por quê, recomendo que pule direto para a última sessão do post, no resto eu só discuto pq eu acho a minha solução boa e as outras tentativas com os problemas que tinham. Já aviso: esse post (assim como o resto do Blog) pressupõe que vc tenha conhecimento (mesmo que apenas conceitual) das ferramentas mais usadas para desenvolvimento de sistemas!

O problema

Um problema que eu venho enfrentando nos últimos tempos é como manter o controle de versão do meu currículo em um formato que funcione bem com o git. Quando mando currículo para uma empresa tenho o costume de olhar as qualificações mais importantes para a vaga e, quando for o caso, destacar algumas qualificações mais incomuns que a vaga exija e eu possua. Pra isso eu preciso saber qual versão do meu currículo eu enviei para cada empresa (até pra evitar mal entendido depois em uma possível entrevista). O jeito mais simples é fazendo uma cópia do currículo para cada empresa e fazer as alterações que forem necessárias. Funcionaria relativamente bem dessa maneira, todavia, considerando que, como programador, eu já tenho conhecimento de ferramentas muito mais avançadas do que o sistema de arquivo do computador é conveniente fazer uso dessas ferramentas. Outra utilidade possível do que eu vou apresentar aqui talvez seja para quem é acadêmico e precisa saber quais versões dos papers foram para quem, quando e o que foi mexido. Mas as utilidades não terminam aí: basicamente é possível recuperar qualquer versão de um documento criado e manter várias versões em paralelo sem grande esforço.

Requisitos para uma solução conveniente

Mas tudo isso de nada adianta se a solução final for complicada de fazer alterações como o Latex. Os usuários do Latex me perdoem, eu entendo os benefícios do Latex, ele é excelente, mas eu nunca aprendi a usá-lo devidamente. Também nunca tive paciência para isso (ok, falha minha), sempre que eu precisava fazer alguma alteração acaba perdendo uma tarde inteira lendo documentação, acabei saindo desse formato por conta disso. Uma necessidade é justamente que seja rápido fazer alterações em novas versões, nada melhor para isso do que através de uma interface intuitiva e um formato de arquivo bem maleável. Como tem muito recrutador que exige que currículo em formatos específicos, também é necessário que seja possível exportar, pelo menos, para PDF e DOC.

Caminhando em direção à luz (tentativas de soluções e considerações gerais)

A melhor opção em termos de interface de usuário é o Libre Office Writer, ok, tem o MS Word também (e vários outros na verdade), mas não é nenhum segredo pra quem já leu algum post meu que uso Linux e evito software pirata, além disso, no contexto do problema que eu coloquei no começo do post, o MS Word tem os mesmos problemas que do Libre Office: ele não é feito para funcionar com o sistemas de controle de versão como o git. O git, e os demais sistemas do gênero, são feitos para gerir versões de código de fonte de programas, que em geral (na verdade não conheço exceção) são arquivos de texto puro com nenhuma informação binária. Por isso os arquivos gerados por estes programas não costumam funcionar muito bem com o git.
Até é possível usá-los em conjunto, mas para usar todas as funcionalidades do LibreOffice eu precisaria salvá-lo em formato nativo (odt), que é um zip com vários arquivos XML, que, por usa vez, têm várias tags na mesma linha. Fica impossível de ler! Imagina fazer um diff do git em um arquivo desse tipo? Mais rápido aprender a usar Latex!
Se o problema é que o arquivo salvo é um binário então uma solução seria usar um formato de texto puro, como HTML ou RTF. Comecei tentando montar o arquivo em HTML com o LibreOffice (LO) de vários jeitos, mas sempre dava algum problema quando exportava para outros formatos (como PDF ou Doc do MS Word). Aí eu acabava abrindo o arquivo e mexendo nele na mão (usar LO pra que então?), aí quando abria, o LO bagunçava tudo..... Com o RTF (um formato de 1980 eu acho) funcionava até um pouco melhor, pois é mais dirigido para documentos de texto, como um currículo, do que o HTML, mas várias funcionalidades do LO não ficavam disponíveis e também problema exportando para PDF.....
Bom, foi nessa época que eu migrei pro Latex e criei o repositório do meu currículo. Bom, eu já comentei um pouco sobre o Latex, quem sabe usá-lo bem eu encorajaria a usá-lo, eu achei uma ótima solução, só achei a curva de aprendizado muito íngreme....
Depois de tentar com o Latex e com o HTML/RTF passei por um esquema de tentar descompactar o arquivo odt do LO e versionar os seus xml's.... mas foi quando eu descobri que os xml's do LO são porcamente formatados (ok, pq seriam legíveis? É feito para o próprio LO ler eles....), tem várias tags na mesma linha, pouquíssimas quebras de linha, enfim, um inferno para ler. Eu até cheguei a fazer uma solução eu mesmo para formatar os XML's para deixar mais amigável de ler..... O problema é que quase sempre acaba quebrando o conteúdo do arquivo ao colocar quebras de linha para melhorar a legibilidade. Então em determinadas situações eu acaba evitando colocar quebras de linha no arquivo formatado.... o que prejudicava a legibilidade do arquivo.......
Acabou que eu mandei tudo às favas e comecei a versionar o binário do odt mesmo. Paciência, nessa altura dos acontecimentos não é difícil imaginar quanto tempo eu já tinha perdido tentando versionar um arquivo de texto..... Uma coisa importante que eu aprendi aqui foi a usar as próprias ferramentas de diff do LO (que ficam no menu Editar / Registrar alterações / Comparar documento...)
Outra solução possível para saber o que foi mexido no arquivo é usar as ferramentas desse mesmo menu, mas elas, por outro lado, não permitem organizar versões em paralelo do mesmo documento, é bom, mas não resolve tudo.

Até que um belo dia eu tropecei neste link aqui. Essa pessoa havia (uns 3 anos antes) tido e resolvido o mesmo problema que eu. O que eu vinha fazendo errado era versionar o mesmo conteúdo que o git gerenciava: pra quem não sabe o git tem um mecanismo para resolver o problema do versionamento de binários: é possível versionar um arquivo e visualizar a saída de um comando nos diff's. Era a solução que eu tanto procurei. Na próxima sessão detalho como ela funciona.

Uma solução funcional que atende a todos os requisitos

Uma vez que as responsabilidades de versionar e visualizar diferenças entre versões do mesmo arquivo podem ser separadas é possível versionar um binário sem os inconveniente de não saber o que mudou de uma versão para outra. Porém, para que isso seja possível é preciso que uma saída em texto puro seja gerada por algum comando do terminal seja gerado sempre que uma diferença entre dois arquivos for solicitada. Então primeiro é preciso criar esse comando:

#!/usr/bin/env sh
set -o errexit
/usr/bin/odt2txt --raw "$@" | /usr/bin/xmllint --format -

Salve o arquivo acima em algum lugar do seu PATH com o nome 'odt2prettytxt'.

Repare na última linha: ela possui dois comandos que não fazem parte do Linux: se vc estiver usando o Manjaro instale os pacotes odt2txt e libxml2, não sei em quais pacotes estes comandos ficam no Debian/Ubuntu. No Archlinux provavelmente os pacotes são os mesmos.

Depois disso só fica faltando informar para o git que para arquivos .odt não é pra fazer o diff com o arquivo informado, é pra passar o arquivo para o nosso script e fazer o diff com a saída do comando:

git config --global diff.odt.textconv odt2prettytxt

Até aqui é a mesma coisa que o Robert Riemann fala no link dele. O que ele deixa passar é que LO polui MUITO os arquivos gerados com um monte de estilos automáticos toda vez que uma alteração é feita. É possível evitar isso selecionando todo o texto (Ctrl+A) limpando toda a formatação direta (Ctrl+M), recarregando o arquivo (menu Arquivo / Recarregar ) e fazendo uma nova limpeza da formatação direta no documento (desse vez sem texto selecionado).

Pronto! No diff ficam apenas as alterações feitas no arquivo e no documento final não fica nenhuma alteração desnecessária!