Em busca do NAS doméstico (quase) gratuito! - Parte 5 - VPN

Pessoal,

Vou dar continuidade ao desenvolvimento do meu NAS doméstico (quase) gratuito.

Um ponto que sempre pegou para mim, como já coloquei em posts anteriores, é a necessidade de acessar os dados do meu NAS (e consequentemente da minha rede doméstica) de fora de casa.

Ora, ter os dados apenas dentro de casa não resolve muito. Um NAS que se prese tem que não apenas gerenciar o armazenamento de dados mas também permitir seu acesso no momento oportuno.

Então, como diria Jack, vamos por partes: primeira, obter um acesso externo de um modo seguro à minha rede local; segundo, resolver um NAS que atenda as necessidades de confiabilidade e acesso tanto por computador quanto por dispositivo móvel.

Acesso a rede doméstica

Como falei aqui, descobri a duras penas que eu tinha um grande problema com os roteadores.

O roteador da NET estava habilitado a toda e gerava um IP por DHCP para o Google Wifi que gerava os IPs também por DHCP para os equipamentos na rede local. Ou seja, abrir uma porta para um IP local seria, além de difícil, arriscado. Para abrir uma porta, teria que abrir primeiro no router da NET e direcionar para o IP do Google Wifi. Assim, pela lógica, essa porta estaria aberta para todos os equipamentos da rede interna,  independente do IP delas ou se houvesse ou não necessidade para isso. Mas nem isso funcionava.

Assim, coloquei o router da NET em bridge (já falei aqui) e fui estudar um pouco sobre NAT (Network Address Translation), Virtual Server, Port Triggering e DMZ Host.

Mas tudo isso mudou quando relembrei de uma vez que tentei, sem sucesso, criar uma VPN. Na época nem sabia bem para que isso poderia me ajudar, acho que fui instalar para aprender mesmo, sem utilidade prática. Não seria uma VPN para acessar um conteúdo no exterior (falei disso bem no começo do blog, lá em 2010!). Meu objetivo aqui é ligar dois pontos seguros: minha rede local e meu notebook ou celular. Sei onde está a entrada e saída dos dados.

Na época, quando tentei fazer essa VPN, utilizei o PiVPN, fazendo do RP3B+ um servidor de VPN. Não funcionou e hoje suspeito que seja por conflito de IP dos roteadores. Como bypassei o da NET colocando ele em bridge, espero que dê certo desta vez.

Antes de tudo, fiz uma instalação limpa no cartão do RP com o Raspberry Pi OS. Depois instalei o OpenMediaVault (veja como instalar facilmente aqui). O objetivo era ter um HD na rede para testes e saber se a VPN funcionaria bem mesmo. Tudo pronto, vamos à VPN em si.

Optei pelo PiVPN. O processo é fácil, tá bem explicado e tem vários tutoriais na Internet. Gostei muito deste vídeo do Lon Seidman no Lon.TV, um dos melhores do YouTube.

Uma das vantagens do PiVPN é a facilidade para instalação. Outra é que o processo já cria a chave para criptografia durante a instalação.

Para iniciar a instalação, abra o Console do RP (ou Putty ou Terminal, se estiver usando SSH) e digite:

    sudo curl -L https://install.pivpn.io | bash

A instalação vai começar e algumas telas serão mostradas:

Um ponto importante é que, como todo servidor, o PiVPN necessita ter um IP Estático. Além disso, o cliente VPN (o celular ou o notebook) precisará saber para qual IP válido (o IP fornecido pelo provedor, ISP) ele deverá mandar a requisição. Vou falar disso daqui a pouco.

Definir um IP fixo na rede doméstica é fácil. Entre no seu roteador e procure por reservar de IP, reserva de endereços no DHCP ou algo assim. Cada router tem um nome pra isso. Aqui o meu já estava fixado (o RP, pela conexão ethernet, sempre tem esse IP).

Escolha como você vai se conectar, cabo ou wifi. O recomendado para um server sempre é cabo devido a estabilidade. Assim, escolhi eth0.

Confirme se o IP está certo e vamos em frente.

Agora o PiVPN deseja saber onde será guardada as informações do OVPN. Como só tenho um usuário no RP, as configurações serão guardadas em /home/pi/ovpns. Nesta pasta ficará guardada a chave de criptografia que será transferida para o cliente posteriormente.

O sistema agora perguntará se desejamos permitir a instalação automática das atualizações de segurança. Por motivos óbvios, a resposta só pode ser SIM.

Agora escolheremos o protocolo que o PiVPN utilizará, UDP ou TCP (veja a diferença aqui, muito bem explicado) e a porta que deverá ser utilizada. Por padrão o PiVPN escolhe o protocolo UDP e a porta 1194. Eu optei por manter o protocolo UDP, mas troquei a porta por segurança (existem portas que não devem ser utilizadas; o sistema tem 65.536 portas e algumas -veja aqui e aqui devem ser evitadas porque normalmente são utilizadas).

Nesse momento, você deverá retornar ao seu router e reservar, no IP fixado para o RP, qual a porta escolhida para receber o fluxo externo, a porta do fluxo interno (geralmente a mesma) e registrar qual o protocolo deseja utilizar (TCP, UDP ou ambos).

Agora será perguntado sobre nível de encriptação das chaves. Escolha 2048 ou 4096. É a segurança de seus dados e da sua rede doméstica que está em jogo. Jogue para ganhar.

Agora vamos ter mais um pouco de teoria para continuar o processo.

As operadoras fornecem um IP para cada computador conectado na rede. Esse IP é conhecido como IP válido ou IP público (IP atribuído pelo órgão regulador). Para saber se um IP é válido ou não, é só saber o seguinte:

    -> 10.x.x.x

    -> de 172.16.x.x a 172.32.x.x

    -> 192.168.x.x

Todos os IPs que estejam nessa regra de cima NÃO são IPs válidos, servem apenas para uso em redes locais. Fora isso, são IPs válidos (e distribuídos pela sua ISP ou por um órgão regulador).

Os IPs geralmente estão distribuídos na versão 4 (famoso IPv4). Esse endereços têm 32 bits de comprimento e existem 2ˆ32 endereços IPv4 (cerca de 4,3 bilhões de endereços). Com o aumento dos dispositivos conectados, esses endereços são insuficiente. Assim, existem duas saídas: a melhor para o usuário e a melhor para a operadora.

A melhor saída para o usuário é a adoção do IPv6. Aqui os endereços têm 128bits e existem 2ˆ128 endereços IPv6 (cerca de 340 duodecilhões de endereços, 340 seguido de 12 zeros...). Assim, cada dispositivo na rede teria seu endereço fixo (um IP válido para cada equipamento na rede).

MAS (sempre tem um mas...) nem todos os servidores e roteadores suportam IPv6. Tirando a questão de bugs e outros problemas que ainda podem existir. Como sempre, vale a regra do "MAS": nada depois de um MAS pode ser bom!

As operadoras resolveram isso de outra forma: CGNAT. Resumidamente, com a escassez de endereços IPv4 (tem mais equipamento na rede que endereço), eles distribuem os endereços entre que está ativo e podem trocar seu endereço a qualquer momento.

O que isso tem a ver com a nossa VPN? Tudo! O cliente precisa saber qual IP válido ele deve procurar para fazer a requisição do dado. Ora, se o seu IP válido muda frequentemente, como você pode resolver isso? Ou pagando para ter um IP válido fixo ou utilizado um serviço de Dynamic DNS (DDNS, No-IP, etc).

Esses serviços de DDNS fazem basicamente uma atualização do seu IP válido e o registram em um sistema de domínios (DNS). Ou seja, pegam o seu 189.17.48.190 que a sua ISP atribuiu para você e o registram como fulano.ddns.net. Assim, quem digitar isso vai ser encaminhado para o IP atribuído a esse DNS. Esses serviços geralmente tem um aplicativo que faz automaticamente essa atualização. Alguns roteadores fazem essa atualização também (MAS, sempre o MAS, Google Wifi não tem esse serviço de DDNS...).

Assim, entrei no No-IP, fiz o cadastro e escolhi o nome. Baixei o aplicativo deles para atualização pro Mac, mas como estava tudo rodando no Pi, achei melhor baixar pra lá e deixar o RP fazendo tudo isso. Basicamente fiz isso:

    sudo su #para ficar com super usuário

    cd /usr/local/src

    wget http://www.no-ip.com/client/linux/noip-duc-linux.tar.gz

    tar xzf noip-duc-linux.tar.gz

    cd noip-2.1.9-1

    make

    make install

Agora o programa vai pedir o nome de usuário ou email registrado no No-IP.com, a senha, vai pedir pra você escolher qual nome deseja atualizar e com qual frequência (o padrão é 30 minutos, mas eu escolhi 5 minutos). Depois digite, ainda com SU:

    /usr/local/bin/noip2

Pronto. Agora já temos um DNS ligado ao nosso IP válido e continuamente atualizado.

O próximo passo agora no PiVPN é escolher se quer utilizar o IP público (ou válido) ou escolher um DNS. Obviamente vamos escolher entrar com DNS e colocar o DNS que acabamos de criar no No-IP (lembre-se, é só no DNS, sem "http"):

Agora somos perguntados sobre qual serviço de DNS desejamos usar. Escolhi o Google, mas o OpenDNS também é bem rápido. Falei um pouco disso no final deste post.

Bom, a configuração acaba aqui. Agora falta apenas entrar com os usuários (clientes) da VPN.

Dê um

    pivpn add

e digite o que é pedido: nome do cliente, senha e senha novamente. Nunca é demais reforçar que a senha deve ser boa, né?

Agora, se tudo deu certo, a chave para o cliente foi criada e deverá estar em /home/pi/ovpns. Essa chave deve ser enviada para o cliente. No meu caso, como o cliente sou eu mesmo (será meu notebook, iPad e iPhone), posso passar por três formas: por email (pior opção, insegura), pendrive (tem que lembrar de apagar depois) ou por um serviço de nuvem.

Não se esqueça de liberar essa porta UDP no roteador, em Port Management. Acrescente a regra com a porta escolhida, o padrão de comunicação (UDP, TCP ou ambos) e confira se o MAC Address do servidor é o mesmo que você está liberando.

No Mac instalei o Tunnelblick para acessar a VPN. Arrastei a chave para o ícone do programa, digitei o usuário e a senha e pronto. Fica um pequeno ícone na barra superior e aí é só clicar lá e começar a navegação via VPN.

No iPad e iPhone o processo é um pouco diferente. Para ambos existe aplicativo da OpenVPN que deve ser baixado na AppStore. Depois de baixado, conecte o iDevice ao computador, abra o Finder, selecione seu dispositivo e, à direita, escolha "Arquivos". A seguir arraste a chave para o aplicativo OpenVPN e termine de configurar no iDevice.

Bom, o próximo passo é efetivamente criar um bom NAS.

Utilizando a VPN, tenho a segurança agora de acessar o NAS de fora da rede, qualquer que seja o NAS escolhido.

Pode ser o OpenMediaVault (e ele ficaria apenas para arquivos e/ou TimeMachine). Pode ser o NextCloud (que tem aplicativos que podem ser utilizados nos dispositivos móveis) ou tentar o XPEnology, meu sonho de consumo.

Para o XPEnology, precisarei de uma máquina boa, que permita virtualização.

Lembram do MacMini que morreu no começo do ano? Pois é, descobri uma empresa aqui em BH que tentará recuperar a placa lógica dele. Se der certo, ótimo. Se não der, é pensar no plano B.

Só que esse post acaba por aqui. Obrigado.

Em busca do NAS doméstico (quase) gratuito! - Parte 4 - Abrindo finalmente (ou não) as portas do roteador!

 Pessoal,

Meus pobremas se acabaram-se!! Ou não!

Finalmente consegui entender como abrir as portas do roteador.

No meu roteador da NET tem uma opção: NAT. É aqui que eu tenho que trabalhar. No roteador há três opções:

1 - Virtual Server - permite criar uma conexão que chega pela WAN (identificada pelo protocolo TCP/UDP e porta externa) para um endereço IP interno na LAN (rede local). Nesse serviço, é preciso especificar o IP de destino.

2 - Port Triggering - permite que uma aplicação no lado interno da LAN (rede local) possa acessar um serviço em rede externa por uma porta pré-determinada. Tive a impressão que é meio que o oposto do Virtual Server. Nesse serviço não é preciso especificar o IP interno, uma vez que ele é a fonte, não o destino.

3 - Host DMZ - o roteador vai encaminhar ao IP de destino todos os pacotes que chegarem via WAN. Ou seja, todas as portas estão abertas, mas apenas para determinado IP.

Ou seja, pelo que entendi, o Virtual Server libera que uma porta determinada receba um fluxo externo -> interno para o IP especificado da rede local. O Port Triggering libera que um IP especificado na rede local acesse um serviço externo (fluxo interno -> externo) por uma porta pré-selecionada. E a última opção, o Host DMZ, permite um fluxo externo-> interno para determinado IP especificado na rede local (tipo o Virtual Server), porém para qualquer porta que o serviço externo queira acessar na rede interna.

O complicado no meu caso é que eu tenho um roteador dentro da rede de outro roteador. Ou seja, o IP do primeiro roteador (da NET) gerado pelo DHCP é um e o IP gerado pelo segundo roteador (o Google Wifi) é outro. Ou seja, a NET especifica um IP para o Google Wifi e este distribui outros IPs via DHCP para a minha rede local.

Fiz um teste com o Transmission (programa para baixar Torrent no Mac). Criei um Virtual Server no roteador da NET, mas especifiquei o IP do Google Wifi. A porta do Transmission que estava fechada, foi aberta. Mas pelo que entendi, a porta X aberta no Google Wifi abriu a porta X de todos os IPs da rede local. Confere, produção?

Bom, essa não é a solução que eu procuro. Meu plano passou a ser outro: colocar o roteador da NET em bridge, ou seja, ele será apenas uma ponte do serviço externo da NET para o Google Wifi. Esse é quem definirá as portas a serem abertas, os endereços IP por DHCP para cada equipamento, etc.

Então foi isso que fiz: liguei o MacBook no roteador da NET por cabo (na porta 1), desativei o Wifi (eu tinha deixado o Wifi 5GHz ativado para poder acessar, caso precisasse mas não tinha nado ligado nessa rede) e mudei para modo Bridge. Instantaneamente a internet pelo roteador da NET acabou (passaria a ser apenas pelo Google Wifi na hora que eu ligasse ele no roteador da NET).

O próximo passo foi esse, ligar o Google Wifi no roteador da NET, na porta 1. A internet voltou e pronto, passo encerrado.

Depois resolvi dar uma olhada mais atenta nas configurações do Google Wifi, uma vez que ele é a única  barreira agora.

Primeira coisa: baixei o DNS Benchmark para ver qual DNS estava melhor por agora. Antes eu estava usando o DNS do Google (DNS primário 8.8.8.8 e secundário 8.8.4.4). Minha internet tinha tido uma queda razoável e eu estava atribuindo isso a alguma decisão da NET de reduzir a velocidade de todo mundo devido a quarentena. A velocidade contratada era de 100Mbps e estava rodando entre 30-50Mbps. Como o celular é da CLARO, essa velocidade contratada era dobrada para 200Mbps. Ou seja, 50 tá muito ruim...

Usando o DNS Benchmark, vi que a melhor opção seria o OpenDNS (208.67.220.222 e 208.67.222.220). Entrei nas configurações do Google Wifi e mudei o DNS. Resetado e operante!

Como tirei (acho que tirei, né?) o limite do roteador da NET e arrumei o DNS, fiz um speed test e tive essa surpresa!

Vários testes rodando nesta faixa de 100Mbps. Às vezes alguns vieram mais altos. Mas o recordista foi esse aqui, pelo MacBook Pro do lado do Google Wifi principal:

O upload não tá uma beleza, mas o Download ficou coisa linda de D'us!!!

Bom, a primeira coisa era colocar em bridge e arrumar as configurações do Google Wifi. A segunda coisa agora SERIA realizar a abertura de portas.

Entretanto, para minha alegria, passando por videos no YT sobre como fazer isso, vi um sujeito esbravejando para ninguém abrir portas de roteador por questão de segurança e, se quisesse acessar da internet os arquivos de rede local, que criasse uma VPN (!). Aí lembrei de uma vez que tentei instalar uma VPN e não tinha dado certo. Pensei: será que não tinha dado certo porque eu estava sob dois roteadores?

Vamos lá testar no próximo (e último) post dessa série.

Mighty!

Pessoal,

Conheçam o Mighty!

(Conteúdo da caixa: o Mighty, um cabo de força -carrega pelo P2- e o manual)

Para quem não conhece, esse brinquedinho aí já tem um tempo de estrada. A empresa foi fundada em 2015 e desde 2017 tornou-se parceira do Spotify para música off-line e em 2020 tornou-se parceira da Amazon Music com o mesmo fim.

O Mighty é um player de música pequeno, leve, com conexão bluetooth (para fones de ouvido) e wifi (para receber as músicas). Tem também uma entrada P2 para fones tradicionais com fio.

A bateria dura, segundo o fabricante, cerca de 5 horas de música ininterrupta e armazena mais de 1000 músicas.

O estilo lembra o saudoso e finado iPod Shuffle, o melhor player de música para corrida na minha opinião.

(iPod Shuffle e o Mighty)

(Ambos prendem-se por clip)

O Mighty é maior, mais grosso e mais pesado que o Shuffle. O Shuffle é de alumínio, ou seja, mais resistente. Além disso, a bateria do Shuffle dura MUITO mais que a do Mighty (devido a wifi e BT provavelmente).

Enquanto o Shuffle recebe música APENAS via iTunes, o Mighty recebe músicas apenas pelo Spotify e Amazon Music.

Se o iPod (no caso o Shuffle) trouxe para o seu bolso toda a sua biblioteca musical, o Mighty trouxe toda a biblioteca da Spotify ou Amazon! E elas são imensamente maiores que a minha pessoal :) Mas, por outro lado, só funciona se você for usuário pago desses serviços (Spotify Premium ou Amazon Prime). A Apple tem o Apple Music, mas esse serviço não funciona para o Shuffle.

O Mighty é todo configurado por aplicativo no telefone ou tablet, enquanto o Shuffle era pelo iTunes.

No Mighty, é configurado uma conexão BT com o aplicativo, depois a conexão wifi (para baixar as músicas) e por último a conta do Spotify e/ou Amazon para escolher a playlist a ser baixada para o Mighty. Simples assim. Esse processo precisa ser revalidado a cada 30 dias.

No Shuffle, basta conectar ele no computador pelo USB que o iTunes automaticamente identifica. Você escolher as músicas ou uma playlist e passa para o iPod. Simples assim também.

Problemas

Já tive alguns iPods. Corro desde 2006 com boa regularidade (em breve vou comprar uma esteira e vou comentar sobre ela também) e já tive os equipamentos abaixo:

(iPod Mini 2a geração - 2006 - o disco interno morreu 😭😭)

(iPod shuffle 2a geração - o conector P2 interno parou de funcionar -curto? ferrugem?)

(iPod shuffle 4a geração A1373 e iPod Nano 5a geração - ambos funcionam)

Ainda utilizo o Shuffle; o Nano estava no meu carro servindo como armazenamento de música até quando troquei de carro e veio um com Apple CarPlay.

Já Mighty estou no meu segundo modelo. No primeiro, a bateria abriu o bico com pouco mais de um ano. Além disso, o Mighty é meio lento para passar as músicas.

Por que estou com outro Mighty? Porque ganhei esse outro! Comprei para um colega que nunca usou (porque não quis pagar o Spotify Premium) e resolveu me dar o dele. Ótimo! :)

Outra coisa: fones de ouvido!

Já tive alguns fones e, para mim (e sei que isto é muito pessoal e individual), os fones in-ear são péssimos. Como corro na rua, fico muito isolado do mundo externo com esses fones e é até perigoso, mas o pior é que os acho extremamente desagradáveis de usar.

Já tive alguns genéricos, alguns de marca. Mas os que melhor adaptaram-se ao formato da minha orelha foram os da Apple. Tanto faz ser eram os de iPod ou os de iPhone. São os melhores para mim. A qualidade do som é boa e os fones ficam bem ajustados.

Esse iPod shuffle tá comigo desde 2012. Aguentou treinos em condições ruins (muito sol, chuva), correu comigo em Londres, aguentou os treinos para a meia maratona de Amsterdam e para a maratona do Rio. Foi aposentado em 2018 quando o Mighty chegou. Quando o Mighty morreu, no começo do ano, ele voltou ao serviço e mostrou que ainda estava em forma.

Os produtos da Apple, como qualquer coisa produzida em série, tem equipamentos com problema. Mas convenhamos: esse Shuffle com 8 anos de uso intenso é uma prova que a coisa custa caro (nem foi tão caro assim, foi US$ 50.00 quando o dólar era barato) mas funciona maravilhosamente bem!

Até o próximo!

Criando um pendrive bootável para instalar o MacOS

Pessoal,

Esse assunto tem tudo a ver com o post anterior. Vamos em frente.

Para instalar o MacOS a partir do nada, supondo que esteja utilizado um Mac de verdade, pode ser utilizado um pendrive bootável ou reinstalar o MacOS utilizando a Recuperação do MacOS.

Utilizar a Recuperação do MacOS é a forma mais "fácil". Esse fácil ficou entre aspas porque depende de dar certo (aí é fácil) ou não (aí não é fácil).

Ligando o computador e apertando uma sequência de teclas que sempre terão Command e R, você terá três opções:

1 - Instalar a versão que estava instalado no Mac (Command + R);

2 - Instalar a versão mais atual para o Mac em questão (Command + R + Option);

3 - Instalar a versão de fábrica do Mac em questão (Command + R + Option + Shift).

O artigo linkado acima, da Apple, está bem explicado. Assim, se eu quiser formatar o meu MacBook e fazer uma instalação do zero (ou colocar um HD/SSD novo, por exemplo), será baixado a versão fornecida no Mac (e deverá ser atualizado depois). Vale a pena ler isso aqui também.

 A outra forma de instalar o MacOS é utilizando um pendrive bootável (ou inicializável). Para isso, você deve ter a imagem já baixada. A Apple disponibiliza o link para isso aqui. A Apple também ensina o processo todo nesse mesmo artigo.

No meu caso, para fazer o pendrive para o High Sierra (para o MacBook White), tenho que baixar o instalador do High Sierra que ficará em "Aplicativos" com o nome "Instalação do MacOS High Sierra". Coloque o pendrive (pelo menos 12GB) formatado para Mac OS Expandido com registro cronológico (ou Journaling) e o esquema tem que ser "Mapa de Partição GUID"., abra o Terminal e digite o seguinte (troque o MyVolume pelo nome do seu pendrive ou simplifique sua vida dando o nome de MyVolume para o seu pendrive #FicaDica):

sudo /Applications/Install\ macOS\ High\ Sierra.app/Contents/Resources/createinstallmedia --volume /Volumes/MyVolume

Após terminar, vá no menu Apple (a maçã lá em cima à esquerda), Preferências do Sistema e clique em "Disco de Inicialização", escolha o pendrive que você acabou de criar e escolha "Reiniciar" ou então ligue o Mac onde será instalado já com o pendrive conectado apertando "Option" e escolha o pendrive para instalar.

Esse é o jeito mais simples de criar um pendrive bootável para a instalação do MacOS.

Por enquanto é isso. Até a próxima.

Em busca do NAS doméstico (quase) gratuito! - Parte 3

 Pessoal,

Na primeira parte dessa busca por um NAS doméstico que seja funcional e (quase) gratuito, falei do OpenMediaVault no Raspberry Pi. Funcionou, mas ele não dá acesso (até onde sei) a aplicativos em smartphone e tablets para acessar externamente e isso é fundamental para mim.

Na segunda parte, falei da instalação do Ubuntu Server e NextCloud no que eu tinha disponível aqui para tentar: um Dell Latitude D520 (não funcionou), um FNACBox (também não funfou) e um MacBook White late 2009 (nesse funcionou).

Antes de ir em frente com a proposta de hoje, vou relatar alguns problemas:

1 - O Ubuntu Server só funcionava com a tampa aberta. Se fechasse a tampa, tchau NextCloud. Descobri que acessando o arquivo "logind.conf", é possível arrumar isso. Abra o terminal e digite isso:

    sudo gedit /etc/systemd/logind.conf

Esse comando vai abrir o Gedit, mas você pode usar o Nano ou outro editor de sua preferência. Com o arquivo aberto, procure a linha "#HandleLidSwitch=suspend". O símbolo "#" apenas diz que é um comentário; assim, apague o # para o comando ser executado.

Aqui existem três possibilidades para colocar no lugar do  "suspend": "poweroff" para desligar o computador, "hibernate" para hibernar quando a tampa for fechada e "ignore" para não fazer nada. Essa última é o que eu quero e a linha, depois de editar, ficará assim:

    HandleLidSwitch=ignore

Agora digite uma das duas linhas abaixo ou reinicie o computador para aplicar as mudanças:

    sudo restart systemd-logind

Ou

    systemctl restart systemd-logind.service

Pronto. Agora você pode fechar a tampa do notebook e o Ubuntu Server continuará a funcionar.

2 - Tive um puta problema com o MacBook. Tive problema para atualizar o MacOS, ele entrou em um modo texto que nem o serviço da Apple sabia o que era. Lendo mais atentamente as mensagens, apareceu uma opção de comando "exit". Digitei e voltou para o MacOS.

O problema é que eu não tinha uma cópia do High Sierra para criar um pendrive bootável e reinstalar o MacOS. O suporte da Apple me passou o link do El Capitan e isso é o suficiente para reinstalar o MacOS.

Outra opção é, sem utilizar nenhum pendrive, é ligar o Mac apertando "Command + Option + R" para ligar no modo de instalação e baixar a versão mais nova compatível com o Mac.

Uma terceira opção, não a minha favorita, é utilizar um patcher para baixar o MacOS. Fico um pouco preocupado com a fonte desse MacOS, mas no desespero, pode ser uma opção. Como teste, baixei o MacOs High Sierra Patcher e, ao invés de fazer o patch para instalar, baixei o MacOS:

Eles dizem que o download é direto dos servidores da Apple, mas vai saber. Prefiro a opção de ter certeza que vou baixar o original de verdade.

Quando coloquei o SSD no Macbook White, em 2018, consegui baixar o High Sierra do site da Apple, mas agora fala que não está mais disponível para o MacMini ou o MacBook Pro. Mas como consegui religar o MacBook White, encontrei um artigo da Apple que ensina a atualizar para o High Sierra e coloquei para baixar. Vou deixar uma cópia gravada para sempre :)

(Esse download vai ser super rápido... #SQN)

Ainda um pouco sobre o MacOS Patcher: ele permite instalar o Catalina para computadores que não permitem a instalação dessa versão. Conheci esse programa no vídeo do Gabriel de Pinho, no Youtube. Como disse antes, fico meio temeroso de fazer isso com uma versão de origem suspeita, mas aí vai de cada um e depende de cada desespero.

Assim, antes de fazer o plano B para o NAS doméstico (o plano A é comprar um Synology ou QNAP, mas pagar 5000 Mitos em um produto sem HD nenhum e sem ter a certeza que será exatamente como eu quero, é complicado. Além disso, lá nos EUA, os modelos que eu gostaria custam entre 300 e 400 Trumps, que dá uns 1500 a 2000 Mitos (hoje T$ 1.00 tá dando M$ 5,50; também sem HD, mas a gente acha opção "promocional" pelo mesmo preço ou um pouquinho mais caro já com os HDs).

Bom, ainda vou falar mais dois pontos antes de ir pra parte 4 desse assunto.

Até a próxima.

Em busca do NAS doméstico (quase) gratuito! - Parte 2

Pessoal,

Na primeira parte dessa busca por um NAS doméstico que seja funcional e (quase) gratuito, falei do OpenMediaVault no Raspberry Pi. Funcionou, mas ainda faltou uma parte importante: utilizar aplicativos em smartphone e tablets para acessar externamente.

Agora vou tentar outra coisa "mais profissional". Assistindo alguns videos no canal Diolinux no Youtube, achei duas postagens muito interessantes: Ubuntu Server e NextCloud.

A ideia aqui é instalar um servidor (utilizarei o Ubuntu Server) e depois instalar o NextCloud.

Como o Ubuntu Server é muito leve, configurações menos robustas devem servir. Menos robustas é diferente de computador sucata, como descobri. Tentei utilizar um Dell Latitute D520 (esse da foto) com um Processador Intel Core Duo T2300 1.66GHz e 2GB de RAM. Não deu por ser 32 bits. 😭😭 Então tentei com um FNACBox que tá encostado aqui também. Ele tem um Intel Atom N270 e 2GB de RAM. Como vim a descobrir, também é 32 bits e não funcionou. 😭😭

(Irmão gêmeo do meu Dell D520)

Minha esposa tem um Dell mais novo, como Core i5. Espetei o pendrive do Ubuntu e deu sinais de funcionar bem. Ou seja, a questão é ser 64 bits ou não.

Pensei em comprar um computador usado, bem simples, para fazer esse servidor. Cheguei a olhar no Mercado Livre e OLX por algum equipamento simples, como um i3 ou i5, colocar uns 8 ou 16GB de RAM e um SSD de 128GB para o sistema (porque o armazenamento deverá ser em discos extras, não pode ser no disco do sistema). Como não precisarei de monitor, teclado e mouse, uma vez que o acesso será remoto, poderei enfiar isso em qualquer canto desde que chegue o cabo de rede e energia.

A minha dúvida é: funciona? é viável/utilizável? Sim, porque gastar mil e poucos reais num equipamento que não vai fazer o que eu quero, é desperdiçar dinheiro.

Pensei num NAS "profissional", mas aí, primeiro, fugiria ao escopo deste blog e deste projeto (ser gratuito ou o mais próximo disso) e, segundo, não teria graça!

Opções profissionais não faltam: QNAP TS-251+ ou TS-253be ou 253D me atendem. O Synology DS720+ também atende tudo. Existem algumas diferenças entre os dois, mas basicamente são a mesma coisa: o QNAP foca muito em hardware, o Synology em software. O SO do QNAP permite controle profundo de tudo, mas dizem ser difícil de configurar devido ao excesso de opções. O SO da Synology, ao contrário, dizem ser superacessível e bem user-friendly. Não sei, mas gostei mais da descrição do QNAP :)

O problema do QNAP e Synology é o preço: nos EUA, esses modelos custam entre 300 e 400 dólares. Aqui no Brasil na faixa de 5000 reais! CINCO MIL REAIS. E não tem disco! Os discos bons para servidores custam uns mil reais cada! Outro problema é que ambos tem a limitação de discos. Se tem duas baias, cabe dois discos. Até pode por expansão, mas existe uma limitação.

Basicamente, ambos permitem acesso de arquivos de fora da minha rede, instalação de software para edição de textos e tabelas online (ao estilo Google Docs), criação e acesso online a máquinas virtuais (por exemplo, posso rodar um aplicativo de Windows no servidor em uma máquina virtual e acessar de qualquer lugar do mundo esse aplicativo através de um browser), servidor de mídia e por aí vai. O MyCloud da Western Digital foi uma grande decepção para este fim de acessar os arquivos fora de casa - é lento, burocrático. Não me atendeu. Utilizo hoje em dia com um backup em rede.

Outra opção seria instalar o XPEnology. Nesse caso, o XPEnology utiliza um bootloader para acessar uma imagem do DSM (Disk Station Manager - SO da Synology) e permitir a instalação em um PC. Tentei tanto com o Dell quanto o FNACBox mas esbarrei no mesmo problema de antes.

Pensei em fazer uma máquina virtual e utilizar assim: uma VM rodando dentro do MacMini; esta VM rodaria o servidor Linux (Ubuntu Server com NextCloud ou XPEnology). Não sei porque, mas acho que não ficaria bom...

Assim, queria fazer um teste antes de arriscar comprar um computador para ficar dedicado. Decidi fazer o seguinte: usar meu MacBook White como teste. Obviamente não vou formatar a criança, mas vou fazer um "Boot Camp" nele. Boot Camp no caso entre aspas, porque isso é só para Windows. Para Linux, como não poderia deixar de ser, o buraco é um pouquinho mais embaixo.

O PPLWare, um excelente site de tecnologia português, do grupo SAPO, tem um bom tutorial sobre isso.

Basicamente é necessario desbloquear o SIP (System Integrity Protection) do Mac para permitir isso. Vamos instalar um bootloader para MacOS e Linux, o rEFInd. Depois de fazer o download, abra a pasta e arraste o arquivo "refind-install" para o Terminal do Mac (como não fotografei a minha tela neste momento, vou utilizar as fotos da PPLWare - as duas primeiras apenas):

Veja o alerta "SIP Enable". É precisamente isto que queremos desativar. Para tanto, reiniciei o Mac apertando Command+R para acessar o Utilitário do MacOS. Então abri o Terminal (dentro de Utilitários) e utilizei o comando "csrutil desable" (sem aspas, obviamente). Para reativar o SIP é só entrar novamente aqui e digitar "csrutil enable".

(Repare que o SIP foi desativado)

(Repare que reativei o SIP com "enable"e desativei com "desable")

Depois desse processo, reinicie o Mac e arrastei o  "refind-install" para o Terminal novamente. Agora deu tudo certo.

Agora é criar a partição onde o Ubuntu será instalado: vá em Aplicativos -> Utilitários -> Utilitário de Disco e selecione "Particionar".

Agora vamos clicar nesse "+" embaixo do círculo para criar o número de partições que desejamos. Criei apenas uma

Repare que a partição a ser criada deverá ser "MS-DOS (FAT)". O próprio sistema determinou o tamanho máximo que eu poderia alocar para esta partição - 52GB. Clique em "Aplicar".

Daqui pra frente vou fazer a instação do Ubuntu Server e NextCloud. Para instalar o XPEnology é a mesma coisa até aqui. Como teste, criarei mais uma partição para instalá-lo, mas isso vai ser um novo post (parte 3).

Alguns minutos depois deu o aviso de "ok"! Pronto. Agora temos duas coisas para fazer: download do Ubuntu Server e gravar a imagem em um pendrive (usei o balenaEtcher) para isso.

Após instalar o rEFInd, testei a reinicialização do Mac. Apareceu assim:

Escolhi a opção "Boot from Macintosh HD" e entrou normal. Não gostei de ser sempre assim. Prefiro a escolha do Boot Camp, onde você clica em Option na hora de iniciar e escolhe a partição que quiser iniciar e ela será sempre a opção de escolha até que você clique em Option novamente e escolha outra partição. Mas tem a possibilidade de bloquear o SIP novamente, então vamos em frente.

Agora vamos à hora da verdade: instalar o Ubuntu no MacBook. Quando reiniciar a máquina, vai aparecer a imagem do rEFInd mas vai mostrar um pinguim. Clique nesse pinguim para começar.

Momento nerd: o nome desse pinguim é Tux e ele é o mascote do Linux Kernel, apesar que esse do rEFInd parece mais o Penta do Antarctic Adventure da Konami:

(Tux)

 

(Penta - Antarctic Adventure ou Penguin Adventure - Konami)

Voltamos à nossa programação normal. Após clicar no pinguim da imagem, apareceu isso e escolhi a primeira opção.

A partir daqui tive um pouco de dificuldade. Segui basicamente o que o Diolinux falou no vídeo no YT, pra ir lendo mas seria tudo só dar ok.

Como eu estou fazendo em um SSD dual boot, tive que escolher umas das partições disponíveis (escolhi a opção 3 - 48GB). Tive que mudar a formatação para ext4 e montar em [/ ].

No final pediu para reiniciar: mandei reiniciar, tirei o pendrive e mandei ficha.

Apareceu isso aqui:

Vejam que apareceu o símbolo do Ubuntu. Cliquei nele e começou a carregar o servidor. Demorou uns minutos, mas foi.

Outra coisa importante de dizer: antes de tudo isso, coloquei um cabo de rede no Macbook White (sim, ele tem entrada Ethernet) e vi qual endereço IP o roteador separou para ele e reservei esse endereço (veja aqui como).

Para tudo ficar funcionando, instalei o "net-tools":

        sudo apt-get install net-tools

De rotina, verifico se tem atualização com:

        sudo apt update

E atualizo com:

        sudo apt dist-upgrade

Para acessar remotamente o servidor, instale o servidor SSH. Eu já havia solicitado a instalação durante a instalação do Ubuntu, mas se você não fez, faça agora com:

        sudo apt install openssh-server

 Inicie o SSH com:

        sudo service ssh start

A partir daí, fiz tudo pelo MacMini entrando no Terminal e acessando através de:

        ssh <nome_que_você_escolheu>@<ip_que_você_reservou>

Confime digitando "yes" e a senha. Pronto.

A minha ideia era simplesmente instalar o NextCloud. Mas aí descobri a opção de instalar o OnlyOffice com o NextCloud. Eles tem isso preparado no GitHub. Então instale o Git e depois o docker do OnlyOffice:

        sudo apt install git

        sudo apt install docker docker-compose

E baixe os arquivos do OnlyOffice com NextCloud do Docker:

        git clone https://github.com/ONLYOFFICE/docker-onlyoffice-nextcloud

Para fazer tudo funcionar com o Docker, entre agora como root (super usuário) e execute o comando:

        sudo su (para entrar como root)

        docker-compose up -d

(execute esse comando no diretório que você baixou docker-onlyoffice-nextcloud)

A essa altura,  o NextCloud já está rodando. Para testar, vá em um navegador e digite o IP do servidor. Deve aparecer isso aqui:

E voilà! NextCloud funcionado!

Ele está rodando no MacBook White e estou acessando ele pelo MacMini. E existe aplicativo do NextCloud para iOS e Android! Eita que se tiver Virtual Machine para essa bagaço o XPEnology vai subir no telhado!

Após a configuração inicial do NextCloud, é necessário habilitar o OnlyOffice. No Terminal do servidor, digite:

        bash set_configuration.sh

Bom galera, é isso.

Vou tentar absorver um pouco disso tudo e vejo o que mais dá para fazer ou se vou pro XPEnology. Conto o resultado aqui.

Valeu.