Parte 1. Seleção de computadores e componentes
Os principais requisitos para um servidor doméstico eram compactação e baixo consumo de energia. Como computador, considerei vários dispositivos de placa única e até pensei em dispositivos de placa única na arquitetura x64. Os principais critérios de pesquisa foram o excesso de RAM de 8 GB, portas modernas: usb3.0 e gigabit LAN. A ideia era aparafusar tudo em algum tipo de caixa miniATX, usando interfaces usb-sat para discos rígidos. Não gostei dessa percepção esteticamente e não tinha pressa em implementá-la. De repente me deparei com uma baleia americana para a 4ª framboesa dos chineses de Radha.
Pelo que entendi, o próprio chapéu sata já foi apresentado há algum tempo e mesmo muito rapidamente esgotou em uma edição limitada. Mas, desta vez, os chineses também ofereceram uma caixa. Toda a estrutura parecia muito compacta e bonita como se minhas mãos não fossem tão regulares. Pesquisei esta caixa no Google, encontrei uma crítica paga no YouTube e, em princípio, me convinha. Decidi não pensar por muito tempo, pois, muito provavelmente, o lote se esgotaria rapidamente e a fonte de alimentação foi fornecida gratuitamente para a promoção. Uma caixa de chapéu sata com entrega expressa de Shenzhen me custou € 125,23 no momento da compra. A escolha da caixa reduziu automaticamente a escolha dos computadores ao 4º framboesa, que comprei na Amazon por € 79,97 para o modelo com 8 GB de RAM. Também na Amazon foram adquiridos 2 discos rígidos VD 2,5 ”2 TB a € 63,81 cada,e um cartão SD Samsung EVO 120 por € 15,25 no aliexpress. Total € 348,07, achei que o leitor se interessaria pela questão financeira.
Todo esse material é montado de forma muito simples, queridos camaradas chineses cuidaram de tudo, um exemplo pode ser visto na imagem abaixo. Também gravei alguns vídeos curtos do dispositivo montado. Dos momentos agradáveis dos quais não tive consciência na hora de fazer o pedido do aparelho:
- o corpo é feito de uma única peça de metal, pintado na parte externa com tinta branca;
- o fundo com orifícios de ventilação também é de metal;
- parafusos e porcas de montagem: metal (não metal, apenas a tampa translúcida de plástico superior com orifícios para um grande ventilador);
- chapéu de sata da próxima revisão, e não a que o vlogger tinha no YouTube, e tem um conector de bateria;
- uma pequena tela gelada exibe informações sobre o estado do sistema;
- um grande ventilador e uma tela de gelo funcionam instalando o software de Radha, que são scripts python, e são instalados inserindo um comando no terminal.
Por padrão, o ventilador superior possui 4 modos de operação dependendo da temperatura do processador, que diferem na intensidade da rotação e no ruído produzido: no nível 1 é quase inaudível, o nível 2 é audível, 3-4 é audível muito bem. Por isso, de fato, os scripts python são os responsáveis.
Em geral, fiquei satisfeito com este dispositivo, mas tinha um comentário. O kit usa um escudo de gelo em execução, que pode ser facilmente encomendado na Alishechka, mas o escudo é soldado à placa, os chineses não precisaram usar o conector FPC / FCC na placa. Isso simplificaria muito a substituição da tela de gelo em caso de queima, por exemplo.
2.
Bem, está tudo montado, vamos começar a configurar o software. Não irei inundar o copy-paste, portanto, os pontos gerais serão apresentados por links para hauta na linha de pesquisa. Vou pular alguns, mas você pode me alongar nas armadilhas com mais detalhes.
Eu escolhi o sistema operacional ubuntu server 20.04.1, um guia maravilhoso para a instalação do Kanonikl escrito por você. Em seguida, instalamos o software de Radha de acordo com seu mana . Aqui havia uma armadilha número 1. O fato é que para certas necessidades de torrent eu precisava usar VPN, mas meu provedor de VPN não suporta IPv6. Quando configurei o openvpn para meu provedor, descobri que meu anonimato, digamos, flui precisamente pelo IPv6. Bem, ok, no nível do sistema, o IPv6 pode ser desativado no Ubuntu de forma bastante simples.
Como exatamente
sysctl
:
, 6 , :
:
:
$ sudo nano /etc/sysctl.conf
net.ipv6.conf.all.disable_ipv6=1 net.ipv6.conf.default.disable_ipv6=1 net.ipv6.conf.lo.disable_ipv6=1
:
$ sudo sysctl -p
, 6 , :
$ sudo nano /etc/rc.local
:
#!/bin/bash
# /etc/rc.local
/etc/sysctl.d
/etc/init.d/procps restart
exit 0
:
$ sudo chmod 755 /etc/rc.local
Mas então o inesperado aconteceu, o grande ventilador da caixa parou de funcionar.
Tendo excluído a possibilidade de falha de hardware, comecei a procurar uma causa de software. A saída de status do serviço rockpi-sata estava mostrando erros relacionados ao script fan.py python:
ubuntu@ubuntu:~$ sudo service rockpi-sata status
● rockpi-sata.service - Rockpi SATA Hat
Loaded: loaded (/lib/systemd/system/rockpi-sata.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2020-12-25 17:16:07 CET; 11min ago
Main PID: 1879 (python3)
Tasks: 4 (limit: 9252)
CGroup: /system.slice/rockpi-sata.service
├─1879 /usr/bin/python3 /usr/bin/rockpi-sata/main.py on
├─2896 /usr/bin/python3 /usr/bin/rockpi-sata/main.py on
├─2897 /usr/bin/python3 /usr/bin/rockpi-sata/main.py on
└─2898 /usr/bin/python3 /usr/bin/rockpi-sata/main.py on
Dec 25 17:16:57 ubuntu python3[2899]: self._target(*self._args, **self._kwargs)
Dec 25 17:16:57 ubuntu python3[2899]: File “/usr/bin/rockpi-sata/fan.py”, line 81, in running
Dec 25 17:16:57 ubuntu python3[2899]: change_dc(get_dc())
Dec 25 17:16:57 ubuntu python3[2899]: File “/usr/bin/rockpi-sata/fan.py”, line 75, in change_dc
Dec 25 17:16:57 ubuntu python3[2899]: gpio.hardware_PWM(12, 25000, dc * 10000)
Dec 25 17:16:57 ubuntu python3[2899]: File “/usr/local/lib/python3.8/dist-packages/pigpio.py”, line 2044, in hardware_PWM
Dec 25 17:16:57 ubuntu python3[2899]: return _u2i(_pigpio_command_ext(
Dec 25 17:16:57 ubuntu python3[2899]: File “/usr/local/lib/python3.8/dist-packages/pigpio.py”, line 1062, in _pigpio_command_ext
Dec 25 17:16:57 ubuntu python3[2899]: sl.s.sendall(ext)
Dec 25 17:16:57 ubuntu python3[2899]: AttributeError: ‘NoneType’ object has no attribute ‘sendall’
O que não é nada interessante, exceto para o método de inicialização GPIO. Para isso, toda uma classe é escrita lá:
class MockPigpio:
@classmethod
def pi(cls):
try:
host = misc.check_output("netstat -l | grep -o '\S*:8888' | tr -d ':8888'")
gpio = pigpio.pi(host=host)
except Exception:
gpio = cls()
return gpio
def __init__(self):
syslog.syslog('PWM of pigpio is not available. Use on/off to control the fan.')
syslog.syslog('If you use pre-release kernel, please go back to stable release.')
def hardware_PWM(self, pin, _, dc):
misc.set_mode(pin, bool(dc))
gpio = MockPigpio.pi()
Gostaria de saber qual é esse valor usado para inicializar o host, que é exibido pelo comando netstat -l | grep -o '\ S *: 8888' | tr -d ': 8888'?
ipv6-localhost
Se o IPv6 estiver desabilitado, o comando produzirá uma linha vazia e o script não funcionará. Francamente, eu escolhi o caminho longo no início. Eu olhei para o módulo python pigpio.py, no qual a inicialização do host foi descrita em detalhes, descobri que, em princípio, o método pigpio.pi () não precisa de nenhum argumento. Depois de tentar, sem sucesso, as opções para chamar esse método sem argumento, com o argumento lcoalhost e outras opções que não me lembro mais, dentro do script fan.py, percebi que não era mais inteligente que os autores e fui pelo caminho mais fácil. O fato é que o módulo PIGPIO pode ser chamado em modo IPv4, para isso basta editar um arquivo:
$ sudo nano /lib/systemd/system/pigpiod.service
E fixe o parâmetro ExecStart para o seguinte valor
ExecStart=/usr/local/bin/pigpiod -l -m -n 127.0.0.1 -p 8888
Agora o comando netstat -l | grep -o '\ S *: 8888' | tr -d ': 8888' imprime:
localhost
e o ventilador está funcionando!
Parte 3. Separando o tráfego
Além disso, o tipo de ataque 1, samba, openvpn, demônio de transmissão e killswitch para ufv foram configurados. A descrição desses procedimentos, acho que o leitor médio é capaz de pesquisar no Google por conta própria.
O desempenho do dispositivo resultante é, em princípio, normal. Embora eu não entenda onde a velocidade cai durante a cópia. Aqui está um exemplo de cópia de um pai contendo 39 episódios de anime com um tamanho total de cerca de 40 GB.
E aqui está um exemplo de download de um arquivo grande.
Percebe-se que o sistema pode utilizar todo o recurso da rede gigabit sempre que desejar. Ainda não descobri as reduções na velocidade de cópia.
A segunda armadilha não se aplica ao chapéu sata, mas, na verdade, ao servidor Linux como um objeto de cultura material. A tarefa era que o servidor fosse usado para diferentes tarefas: haverá um servidor web (nuvem), que irei bater de fora, e uma bomba de fluxo de bits não selecionada via vpn. O problema acabou sendo que eu precisava separar de alguma forma o tráfego para que tudo funcionasse em paralelo. Meu primeiro pensamento foi configurar um firewall. Usei as seguintes regras:
$ sudo ufw default deny incoming
$ sudo ufw default deny outgoing
$ sudo ufw allow in on eth0 from 192.168.178.1
$ sudo ufw allow out on eth0 to 192.168.178.1
$ sudo ufw allow in on eth0 from 192.168.178.20
$ sudo ufw allow out on eth0 to 192.168.178.20
$ sudo ufw allow in on eth0 from any to any port 22,443 proto tcp
$ sudo ufw allow out on eth0 from any to any port 22,443 proto tcp
$ sudo ufw allow in on eth0 from any to any port 1194 proto udp
$ sudo ufw allow out on eth0 from any to any port 1194 proto udp
$ sudo ufw allow out on tun0 from any to any
$ sudo ufw allow in on tun0 from any to any
Acreditando ingenuamente que tudo funcionará bem. A ideia era que talvez o firewall redirecionasse todas as conexões através do tun0, exceto algumas através do ez0, que uso na rede local, e algumas portas que preciso bater no servidor de fora. Esta configuração funciona bem em uma rede local ou se vpn estiver desabilitado: nenhuma conexão além das permitidas passa. Quando o vpn está ativado, é impossível estabelecer uma conexão externa. Os pacotes chegam, mas as respostas não são redirecionadas pelo ez0, mas ainda assim são enviadas pelo tun0. Passei 2 dias mas ainda não descobri como consertar, então resolvi experimentar o docker, pois o container que eu precisava já está lá.
Esta foi minha primeira experiência com o docker. Foi difícil pra mim, não entendi por onde começar, qual a diferença entre docker e docker-compose, qual o conteúdo do git do link, qual é a imagem, qual é o container, ainda não entendo como consegui construir este container localmente e o que o docker compor baixado da Internet, mas essa coisa funcionou.
Depois de descompactar o repositório, você precisa editar o arquivo docker-compose.yml. E mude seu conteúdo para:
version: '2' services: transmission: image: haugene/transmission-openvpn container_name: vpntrans cap_add: - NET_ADMIN devices: - /dev/net/tun restart: always ports: - "9092:9091" dns: - 8.8.8.8 - 8.8.4.4 # sysctls: - net.ipv6.conf.all.disable_ipv6=1 volumes: - /etc/localtime:/etc/localtime:ro - /mnt/raid0/downloads/:/data environment: - OPENVPN_PROVIDER=SURFSHARK - OPENVPN_CONFIG=mk-skp_udp - OPENVPN_USERNAME=*your username* - OPENVPN_PASSWORD=*your password* - OPENVPN_OPTS=--inactive 3600 --ping 10 --ping-exit 60 - LOCAL_NETWORK=192.168.178.0/24 # proxy: - WEBPROXY_ENABLED=false - TRANSMISSION_PORT_FORWARDING_ENABLED=true - TRANSMISSION_PEER_PORT=51413 - PUID=1000 - PGID=100
Nesta configuração, se você quiser usá-lo para suas necessidades, você terá que prestar atenção aos valores da porta externa (para o contêiner), o caminho para onde o daemon de transmissão salvará os dados, e onde você pode editar suas configurações, insira os parâmetros rede local. Você também precisará configurar seu provedor de VPN na lista . Eu uso um surf shark, o valor do parâmetro OPENVPN_CONFIG determina a escolha da configuração (na verdade, esse valor é o nome do arquivo de configuração necessário) * .ovpn file de um servidor específico ao qual você deseja se conectar. Neste exemplo, o servidor está na República da Macedônia do Norte.
A seguir, criamos e executamos o contêiner com nossas configurações:
$ sudo docker-compose up
Se tudo correr bem, você verá no final do log do cliente openvpn sobre o estabelecimento da conexão bem-sucedida. Bem ou não, você nunca sabe que usa outro provedor de VPN que requer horas de trabalho adicionais. Mas se tudo estiver bem, você pode pressionar cntrl-s e iniciar o contêiner como um processo em segundo plano. A propósito, o contêiner já sabe como se inicializar na inicialização do sistema e reiniciar em caso de erro.
$ sudo docker start vpntrans
Para acalmar sua paranóia, você pode acessar o console dentro do contêiner:
$ sudo docker exec -ti vpntrans /bin/bash
E verifique o endereço IP público:
$ curl ifconfig.co/json
Se tudo corresse bem, a conclusão deveria ser esta:
No entanto, esse teste é de pouca utilidade para acalmar a paranóia pesada, então usei um tubarão e observei as conexões enquanto baixava um torrent com alguma distribuição Linux popular, digamos, ubunta. Tendo excluído da saída conexões não relacionadas a dispositivos na rede local, o servidor vpn, bem como algumas transmissões automáticas, nada de suspeito aconteceu durante o download da imagem do ubuntu:
sudo tshark -i eth0 | grep -v "192.168.178.1" | grep -v "192.168.178.20" | grep -v "185.225.28.109" | grep -v "AVMAudio" | grep -v "SSDP" | grep -v "MDNS" | grep -v "LLMNR"
Mas o que acontece se openvpn perder sua conexão ou o serviço parar repentinamente? O utilitário superior está sendo executado dentro do contêiner, sua saída é semelhante a esta:
Elimine o processo openvpn:
$ kill -9 6
Depois disso, o contêiner foi reiniciado. Mais tarde, li em algum lugar nos fóruns que o contêiner está configurado de forma que se a conexão com o openvpn for perdida ou o processo terminar, o contêiner é simplesmente reiniciado. Esse é o killswitch. Eu estava satisfeito.
Parte 4. Nuvem
Selecionei a nuvem NextCloud e instalei um guia de cada vez . A principal diferença entre minha configuração é que usei outros nabos apache e pkhp:
$ sudo add-apt-repository ppa:ondrej/apache2 $ sudo add-apt-repository ppa:ondrej/php
Depois de configurar o NextCloud, recomendo verificar os avisos no painel de administração e corrigi-los.
Conserta
. . :
:
, . - , , . :
:
:
:
:
, :
);
:
:
$ cd /var/www/nextcloud/
$ sudo -u www-data php occ db:add-missing-indices
:
$ sudo apt install php-bcmath php-imagick
, . - , , . :
$ sudo apt install redis-server php-memcached memcached php-apcu -y
:
$ sudo systemctl start redis-server
$ sudo systemctl enable redis-server
$ sudo systemctl start memcached
$ sudo systemctl enable memcached
:
$ sudo nano /etc/redis/redis.conf
:
port 0 unixsocket /var/run/redis/redis.sock unixsocketperm 700
:
$ sudo usermod -aG redis www-data
, :
$ sudo nano /var/www/nextcloud/config/config.php
);
'memcache.local' => '\OC\Memcache\APCu', 'memcache.locking' => '\\OC\\Memcache\\Redis', 'redis' => array ( 'host' => '/var/run/redis/redis.sock', 'port' => 0, 'timeout' => 0, 'password' => '', 'dbindex' => 0, ),
:
$ sudo nano /etc/php/7.4/apache2/php.ini
opcache.enable=1 opcache.enable_cli=1 opcache.interned_strings_buffer=8 opcache.max_accelerated_files=10000 opcache.memory_consumption=128 opcache.save_comments=1 opcache.revalidate_freq=1
:
$ sudo systemctl restart apache2
A nuvem pode teoricamente ser conectada como uma unidade de rede via WebDAV, mas por algum motivo não no Windows 10. Usando o utilitário Cyberduck, testei a operação da nuvem em uma rede local. Como você pode ver nas imagens abaixo, as velocidades de upload para a nuvem atingem aceitáveis 12 MB / s, e os downloads da nuvem estão em decentes 35 MB / s. Os dados de velocidade foram obtidos com criptografia habilitada na nuvem com a chave pca4096.
Parte 5. Consumo de energia
Inicialmente, eu queria dar a este servidor uma semana para rodar a fim de trazer estatísticas usando o medidor de energia. Mas, infelizmente, não descobri como configurar corretamente este medidor de energia, então darei uma imagem com os dados do indicador. Como você pode ver, no modo inativo, o sistema consome 8,5 W de energia, e durante a sincronização ativa com a nuvem (uma pasta com dados pessoais de cerca de 200 GB de tamanho) até 16,88 W. Estatísticas detalhadas permitiriam calcular o valor médio do consumo de energia por dia, mas devido à sua ausência e pressupondo que o servidor está ocioso a maior parte do tempo, considero 10 W para o valor médio do consumo de energia à primeira vista, que dá:
Com os preços atuais de € 0,31 por 1 kWh, o custo de manutenção do servidor por mês será de cerca de € 2,23, o que não deve afetar muito meu consumo médio de energia.
Uma vez apurado o consumo e os custos, proponho-me fazer uma pequena avaliação dos investimentos financeiros e comparar com as ofertas de servidores virtuais no mercado. Infelizmente, não obtive uma comparação equivalente, porque, pelo que entendi, o mercado de servidores virtuais oferece servidores produtivos ou servidores para armazenamento de dados. Suponha que o servidor doméstico resultante seja comparável em desempenho aos servidores de armazenamento e analise os preços atuais. Como pode ser visto no link, alugar um servidor com 2 TB de espaço em disco custará € 100 por ano. A conta anual de eletricidade do meu minisservidor doméstico no dia 4 do Framboesa deve custar cerca de € 27,16. Com € 348,07 gastos, verifica-se que o retorno do servidor doméstico demorará:
É muito tempo, e o leitor, em princípio, terá razão ao decidir que não vale a pena.
Vamos considerar outra opção com um upgrade para 4 TB de espaço em disco. No caso de um servidor doméstico, eu compraria 2 discos adicionais de 2 TB, que a preços atuais na Amazon totalizariam um adicional de € 127,62. O consumo do servidor terá que crescer e, digamos, em média 18 watts. Isso dará uma conta anual de eletricidade de € 48,88. Agora vamos comparar com o custo de um servidor de armazenamento de 4 TB (€ 340 por ano) e estimar o retorno do investimento:
Isso dura pouco e não parece mais um investimento contraditório.
Conclusão
Neste post nós aprendemos sobre um maravilhoso chapéu sata para a 4ª framboesa e sobre uma baleia fofa baseada nele para um servidor doméstico. Vimos o desempenho deste sistema usando o exemplo de cópia de arquivos pela rede, bem como o desempenho da nuvem NextCloud rodando neste servidor. As questões de consumo de energia, custo e despesas para este servidor também não são deixadas de lado. Obrigado por ler este material. Comentários críticos sobre as soluções apresentadas são bem-vindos.
Em particular, gostaria de pedir ao leitor que compartilhe sua experiência nas seguintes questões:
- ZFS?
- A velocidade de cópia de rede cai, o que fazer a respeito?
- Apache ou é nginks?
- Qual opa escolher?
- Por que o docker está contornando as regras VPN?