domingo, 19 de julho de 2020

Cuidado com versões customizadas de sistemas operacionais que você usa

Cuidado com versões customizadas de sistemas operacionais que você usa

Muita gente gosta de ter um sistema "diferente" nas suas máquinas, seja porque prometem um desempenho melhor em relação ao original, seja para sair da "mesmice" de todo dia ter que olhar a mesma cara e fazer as mesmas coisas no mesmo, entre outras razões. Os sistemas em si (diga-se aí Windows e Android, até mesmo o Linux) em suas versões originais costumam ter muitas gordurinhas que pesam no desempenho final da máquina, com programas que não são usados e ficam ativos sem fazer nada de útil no sistema. Infelizmente muitos desses programas ditos inúteis acabam não podendo ser desinstalados pois há dependências no sistema que eventualmente precisam deles. No Android, tente desinstalar o "Ajuda do Dispositivo" para você ver o que acontece:


Está certo que apps de sistema não podem ser desinstalados, eventualmente podem fazer falta mais tarde para o usuário (como esse ajuda do dispositivo) mas usuários mais avançados gostam de tirar esses programas aparentemente inúteis já que não são usados. Outros exemplos são o Play Filmes e Play Music, o Maps e vários outros.

No Windows e Linux é a mesma coisa mas nesses sistemas já é mais fácil fazer esse tipo de coisa. Hoje em dia nos vemos várias versões personalizadas do Windows (como o Windows Delta 7, Lite ou o MiniOS), tudo muito bonito, sem os eventuais excessos que vem nas suas versões oficiais e até realmente funcionais MAS aí é que entra o alerta: uma versão costumizada (não estou dizendo que uma dessas citadas está nesse grupo, muito pelo contrário) pode conter dentro dela algum truque sacana que vise espionar e/ou roubar dados do usuário sem que ele saiba.

No Windows

No Windows há vários programas de remasterização de uma instalação pré-existente e a vantagem é que o usuário pode encher o sistema de programas de uso do dia a dia, criar a ISO de instalação e distribuir por aí com algum título ou descrição que mostre a vantagem de se baixar e usar esse Windows customizado já que o usuário praticamente não vai ter trabalho de fazer mais nada. O Windows torna-se até mais rápido e fácil de ser utilizado pois, além de estar sem aquela papagaiada do sistema original, ainda pode vir com funcionalidades extras que só podem ser vistas nas versões mais novas do Windows, como novas entradas no menu de contexto e muitas outras mudanças. Essa também é uma boa opção para o eventual sistema que deixou de receber atualizações, como o Windows 7, que é um ótimo sistema e está em uso por muita, mas muita gente ainda hoje em dia.


Mas também há o grande risco de ter nessas remasterizações alguma "brincadeirinha" e até mesmo mudanças em janelas de aviso e serviços de segurança desabilitados apesar de, aparentemente, estarem rodando, como o Windows Defender ou algum antivírus pré-instalado. Um usuário que baixe um sistema desses pode estar abrindo a sua máquina para invasões já que, hoje em dia, é mais prático e sábio ter uma máquina sob o seu domínio do que simplesmente acabar com ela. Uma máquina dominada pode dar fotos e vídeos da tela, senhas e todo tipo de informação que o eventual hacker tenha colocado naquela versão costumizada. E no caso de prejuízo ao usuário, não vai adiantar tentar processar a Microsoft já que não é um sistema "homologado" e sim um piratex fajuto onde o usuário pensou que iria se dar bem...

No Android


O Android segue a mesma linha mas ainda tem um contorno mais complicado. Nos celulares,  o bootloader vem travado de fábrica e o modo root não está disponível, justamente para evitar que sejam instaladas ROMs (o sistema do celular) que não seja a da fabricante e que não possam ser feitas mudanças radicais a nível de sistema, respectivamente. Uma vez que o usuário consiga destravar essas duas opções ele estará apto a instalar as várias ROMs customizadas para celular que tem por aí e caímos então no que acontece no exemplo do  Windows. É até válido usar uma ROM não oficial para que o usuário tenha um sistema mais atualizado e fluído uma vez que a fabricante tenha parado de disponibilizar as atualizações para os seus produtos mas é aí que mora o perigo, pois podem haver ROMs customizadas já famosas como a LineAge OS mas que podem eventualmente terem sido "batizadas" por alguém com programas de acesso remoto e/ou envio de dados que funcionam à revelia do usuário e isso é extremamente perigoso, ainda mais que quase todo mundo usa o celular para compras e acesso bancário. Depois não vai adiantar tentar processar a fabricante do celular reclamando que "vazou" fotos e vídeos íntimos...

No Linux


Também segue a mesma linha dos dois sistemas acima, hoje há uma profusão de distribuições baseadas em alguma outra oficial, notadamente no Ubuntu, que também já foi baseado no Debian mas acabou trilhando um caminho próprio. Essas distros baseadas podem muito bem esconder programas de acesso remoto que funcionam à revelia do usuário e isso não é culpa do sistema e sim de quem eventualmente cria uma distro customizada e coloca dentro dela recursos já pensando em fazer mal aos outros. E também não adianta espernear quando ocorrer algum problema pelo que já foi explicado mais acima.

A customização de sistemas, repetindo, é uma boa maneira de se ter um sistema mais fluído e leve que o original, até mesmo com mais recursos de produtividade e dando até uma sobrevida aos sistemas descontinuados pelos desenvolvedores, já que o usuário eventualmente não pode se dar ao luxo de usar um sistema mais atual, seja por limitação de hardware ou orçamentária. Mas há de se ter cuidado nessas experimentações; na dúvida, não use a máquina em coisas mais sérias que envolvam sistemas bancários ou compras online. Para termos certeza e segurança, é melhor se manter nos sistemas oficiais e procurar na internet como melhorá-los e não pegar um já "melhorado" sob pena de estar levando o bandido para casa. Depois não vai poder reclamar quando tiver seus dados roubados por usar algo do tipo "batizado"...

terça-feira, 14 de julho de 2020

Servidor de arquivos no Debian 10 com controle de grupos e usuários

Servidor de arquivos no Debian 10 com controle de grupos e usuários

Nesta postagem eu fiz um tutorial para fazer um servidor de arquivos simples, onde os usuários locais possuem suas respectivas pastas na rede e uma pasta pública onde os usuários podem acessar à vontade e colocar ali o que quiserem. Agora vamos ver como implementar o servidor de arquivos com um maior controle, baseado em grupos e/ou usuários.

A primeira coisa a fazer é editar os arquivos hostname e hosts e colocar ali o nome desejado ao servidor. O nosso exemplo é "servidor-1".

nano /etc/hostname <ENTER>


nano /etc/hosts <ENTER>


Salve os arquivos e reinicie a máquina. Agora instalamos o Samba:

apt-get install samba <ENTER>

Aguarde a instalação. Vamos então editar o arquivo smb.conf, criar as pastas de compartilhamentos, grupos e usuários para distribuirmos o que é necessário. Primeiro vamos às pastas, grupos e usuários.

Criando as pastas, vamos criar 3 compartilhamentos, um onde todos podem acessar (desde que possuam login no servidor, a pasta não é aberta pra todo mundo na rede), uma segunda pasta para os administradores da "empresa" e uma terceira pasta para o pessoal do financeiro. Vamos criar essas pastas dentro de uma pasta "chefe" pra não confundir com as pastas dos usuários locais que eventualmente existam no servidor.

mkdir -p /home/compartilhamentos/geral <ENTER>
mkdir -p /home/compartilhamentos/administracao <ENTER>
mkdir -p /home/compartilhamentos/financeiro <ENTER>

Damos agora as permissões para as pastas criadas:

chmod 0777 -R /home/compartilhamento/geral <ENTER>
chmod 0777 -R /home/compartilhamento/administracao <ENTER>
chmod 0777 -R /home/compartilhamento/financeiro <ENTER>

Nesse tutorial não vamos criar as pastas de rede pessoais dos usuários, aquela em que apenas o usuário logado tem acesso e os outros não. Se você quiser criar esse compartilhamento, veja o post sobre isso.

Agora vamos criar os usuários. Aqui temos duas situações: criação dos usuários locais "de verdade" e criação de usuários "fake". A diferença é que os usuários "de verdade" vão possuir uma conta local no servidor, aquela conta para poder usar a máquina como um usuário normal; e o "fake" o usuário é criado mas não consegue usar a máquina pois não possui sua pasta pessoal. Essa opção é a melhor para não encher o servidor de contas pessoais que não vão ser usadas e é a que vamos usar.

Vamos criar 6 usuários:

useradd --no-create-home -s /bin/false carlossantos <ENTER>
useradd --no-create-home -s /bin/false sidneiserra <ENTER>
useradd --no-create-home -s /bin/false irineumarinho <ENTER>
useradd --no-create-home -s /bin/false antoniocarlos <ENTER>
useradd --no-create-home -s /bin/false severinosilva <ENTER>
useradd --no-create-home -s /bin/false giselebraga <ENTER>

Inserimos os usuários no Samba:

smbpasswd -a carlossantos <ENTER>
smbpasswd -a sidneiserra <ENTER>
smbpasswd -a irineumarinho <ENTER>
smbpasswd -a antoniocarlos <ENTER>
smbpasswd -a severinosilva <ENTER>
smbpasswd -a giselebraga <ENTER>

Agora vamos criar os grupos:

addgroup geral <ENTER>
addgroup administracao <ENTER>
addgroup financeiro <ENTER>

Botamos então os usuários nos respectivos grupos:

adduser carlossantos administracao <ENTER>
adduser sidneiserra administracao <ENTER>
adduser irineumarinho financeiro <ENTER>
adduser antoniocarlos financeiro <ENTER>

Veja que deixei de fora os usuários severinosilva e giselebraga (e também o grupo Geral), são usuários que não precisam acessar nenhum dos grupos criados mas podem ser inseridos nos grupos mais tarde sem problemas usando o comando "adduser usuário grupo".

Agora vamos editar o arquivo smb.conf. Como é um servidor simples, sem interação com domínio nem nada disso, eu editei o arquivo para o mais simples possível, sem as explicações contidas no próprio arquivo.

#======================= Global Settings =======================

[global]

##As duas linhas abaixo obrigam o usuário a fazer login no servidor com uma conta válida##

restrict anonymous = 2
security = user

##As duas últimas linhas abaixo definem qual interface de rede "escutar"##

workgroup = WORKGROUP
interfaces = 127.0.0.0/8 192.168.3.0/24
bind interfaces only = yes

#### Debugging/Accounting ####

log file = /var/log/samba/log.%m
max log size = 1000
logging = file
panic action = /usr/share/samba/panic-action %d

####### Authentication #######

server role = standalone server
obey pam restrictions = yes
unix password sync = yes
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
pam password change = yes
map to guest = bad user

#======================= Share Definitions =======================
##As linhas abaixo foram desabilitadas pois não vamos criar as pastas de rede do usuário##

#[homes]
#  comment = Home Directories
# browseable = no
#read only = yes
#create mask = 0700
#directory mask = 0700
#valid users = %S

####################FIM do arquivo##########################

Vamos agora a algumas considerações. As linhas que estão em [global]:

restrict anonymous = 2
security = user

são para obrigar o usuário a se logar no servidor, isso evita que um compartilhamento totalmente aberto seja acessado por alguém que não tenha conta no servidor e apague (por exemplo) o conteúdo da pasta compartilhada. Já as linhas:

interfaces = 127.0.0.0/8 192.168.3.0/24
bind interfaces only = yes

define qual rede vai ter acesso aos compartilhamentos, pois um servidor pode ter mais de uma interface de rede e essa configuração especifica qual interface de rede é a de "escuta"; nesse caso, devemos colocar o IP da rede à qual o servidor está conectado na rede local. As linhas:

#[homes]
#  comment = Home Directories
# browseable = no
#read only = yes
#create mask = 0700
#directory mask = 0700
#valid users = %S

foram desabilitadas pois não vamos usar as pastas de rede individuais dos usuários locais.

Vamos agora começar a edição do samba:

nano /etc/samba/smb.conf <ENTER>

Coloque o seguinte na parte de "Share Definitions":

###Acesso geral somente leitura##

[Geral]
comment = Acesso geral sem restrições
path = /home/compartilhamentos/geral
writable = yes
browseable = yes
create mode = 0777
directory mode = 0777

Esse compartilhamento é no estilo "pia de igreja", todo mundo mete a mão e reza, ou seja, o usuário (independente de grupo ou não) entra (se autenticando) e pode fazer o que quiser, colocar e apagar arquivos, criar e apagar pastas, então, é terra sem lei. Você pode melhorar essa história, deixando o compartilhamento apenas como leitura:

[Geral]
comment = Acesso geral sem restrições
path = /home/compartilhamentos/geral
writable = no
browseable = yes
create mode = 0777
directory mode = 0777

Podemos melhorar mais ainda, incluindo um usuário que pode fazer mudanças no compartilhamento, mantendo os outros apenas com privilégios de visualização:

[Geral]
comment = Acesso geral sem restrições
path = /home/compartilhamentos/geral
writable = no
write list = @administradores
browseable = yes
create mode = 0777
directory mode = 0777

A linha write list define qual o usuário ou grupo tem o poder de fazer mudanças (apagar e criar pastas e arquivos). No nosso exemplo, os usuários do grupo administradores tem esse poder. Você pode também usar grupos e usuários:

write list = @administradores, giselebraga

ou apenas usuário(s):

write list = sidneiserra, giselebraga

Um parâmetro interessante a ser usado é:

veto files = /*.mp3/

Esse parâmetro esconde arquivos mp3 já existentes em um compartilhamento e/ou bloqueia a criação ou cópia desses arquivos para o compartilhamento. Se colocado na parte [global]:

[global]

restrict anonymous = 2
security = user
veto files = /*.mp3/

TODOS os compartilhamentos não poderão ter arquivos mp3 e, se já existirem, simplesmente não serão mostrados. Se colocado no compartilhamento:

[Geral]
comment = Acesso geral sem restrições
path = /home/compartilhamentos/geral
writable = yes
browseable = yes
create mode = 0777
directory mode = 0777
veto files = /*.mp3/

apenas o compartilhamento que tenha esse parâmetro será afetado. Agora vamos criar os demais compartilhamentos:

[Administracao]
comment = Acesso restrito ao grupo Administração
path = /home/compartilhamentos/administracao
writable = yes
browseable = yes
create mode = 0777
directory mode = 0777
valid users = @administracao

[Financeiro]
comment = Acesso restrito ao grupo Financeiro 
path = /home/compartilhamentos/financeiro
writable = yes
browseable = yes
create mode = 0777
directory mode = 0777
valid users = @financeiro

A linha valid users define quais usuários e/ou grupos terão acesso ao compartilhamento. No nosso exemplo, o compartilhamento Administração será acessível apenas pelos usuários do grupo administração; o mesmo se dá ao compartilhamento Financeiro e os usuários do grupo financeiro. Se você quiser restringir mais ainda o acesso, você pode usar o parâmetro:

hosts allow = IP da máquina

onde apenas os IPs das máquinas que vão acessar o compartilhamento poderão acessar o mesmo. Por exemplo:

[Financeiro]
comment = Acesso restrito ao grupo Financeiro 
path = /home/compartilhamentos/financeiro
writable = yes
browseable = yes
create mode = 0777
directory mode = 0777
valid users = @financeiro
hosts allow = 192.168.3.110, 192.168.3.111

vai fazer com que apenas os usuários do grupo financeiro e que estejam nas máquinas com os IPs definidos possam acessar o compartilhamento. Há bastante opções extras que podem ser usadas nos compartilhamentos mas vamos deixar isso para outros posts.


quinta-feira, 9 de julho de 2020

Servidor de arquivos simples no Debian 10

Servidor de arquivos simples no Debian 10

Eu já postado aqui no blog um tutorial de criação de servidor de arquivos no Debian, parte usando linha de comando e parte usando um utilitário chamado PHPAdmin mas decidi fazer um novo tutorial com tudo via linha de comando já que, eventualmente, o tutorial anterior pode não funcionar mais. Aqui vamos ver como fazer um servidor de arquivos bem simples, como uma pasta compartilhada a todos os usuários e outra individual e que podem ser acessadas de acordo com as necessidades. A pasta individual só é acessível pelo usuário que fizer login no servidor e a pasta compartilhada todos os usuários que efetuarem login poderão acessar.


Veja que aqui estou mostrando a fazer um servidor simples, sem integração com AD e sem  privilégios condicionais

Primeiro devemos mudar os arquivos hostname e hosts para algo mais "apresentável" na rede, simplesmente para que o usuário saiba qual máquina na rede é a responsável por guardar arquivos dos usuários da rede.

nano /etc/hostname <ENTER>

Mude de acordo com a necessidade, digamos, servidor-arquivos.



Salve o arquivo. Agora deixe o arquivo hosts desse jeito:

nano /etc/hosts <ENTER>


Salve o arquivo e reinicie a máquina. Agora vamos instalar o Samba:

apt-get install samba <ENTER>

Aguarde a finalização da instalação. Se aparecer a pergunta de que você deseja instalar o dhcp-client, pode dizer que não. Uma vez instalado, toda a configuração vai ser feita via o arquivo smb.conf:

nano /etc/samba/smb.conf <ENTER>

Vamos então às configurações. Na parte de Global Settings, coloque a linha abaixo para não permitir a entrada de usuários "convidados" que não tenham se autenticado no servidor:

 
Agora procure o "setor" de networking e vamos fazer a configuração para que apenas uma determinada placa de rede do servidor esteja acessível (no caso de um servidor com mais de uma placa de rede):


O item "interfaces" deve ser configurado com o IP da placa de rede que se quer "bindar" como a de acesso ao servidor às máquinas da rede. No nosso exemplo, a rede é a 192.168.3.0/24. Mude também a opção de "bind interfaces only" para YES. Pode salvar o arquivo mas não o feche ainda. Abra outro Terminal como root e vamos criar os usuários que poderão acessar a rede, crie os usuários de acordo com a necessidade; se já os tem criados, deixe para lá, mas vamos criar o usuário xupeta:

adduser xupeta <ENTER>


e crie também o usuário do samba e sua senha:

smbpasswd -a xupeta <ENTER>

Digite a senha e redigite-a para a criação do usuário. Veja que esse usuário deverá ser o mesmo que você já tenha localmente na máquina, ou seja, se você já tem os usuários criados, basta usar o comando mostrado para criar as suas senhas de acesso no Samba, que podem ser as mesmas do login do usuário na máquina ou uma diferente.

Agora vamos criar a pasta de rede do usuário que vai se autenticar no servidor; essa pasta é do usuário, só ele poderá acessá-la ao se autenticar no servidor:

mkdir /etc/skel/Documents; chmod 0700 /etc/skel/Documents <ENTER>

O nome em verde no último comando pode ser o nome que você desejar, só deve lembrar do nome na hora de continuar a configuração do samba, que é o que vamos fazer agora:


Atenção ao caminho (path) da pasta de compartilhamento criada anteriormente que, aqui, é:

path = /home/%S/Documents

Um detalhe é que você deverá criar a pasta de rede do usuário (e não a compartilhada) para cada usuário que for criado no servidor com o comando:

su - usuario -c 'mkdir ~/Documents; chmod 0700 ~/Documents' <ENTER>

onde o que está em verde é o usuário em si. Então, para criar a pasta de rede para cada usuário já existente e também para os que forem criados posteriormente, basta substituir o que está em verde para o nome do usuário desejado. Mas não há necessidade de se fazer isso caso o usuário não vá acessar a pasta de rede pessoal e a compartilhada.

su - xupeta -c 'mkdir ~/Documents; chmod 0700 ~/Documents' <ENTER>
su - goiaba -c 'mkdir ~/Documents; chmod 0700 ~/Documents' <ENTER>

O próximo passo é definir os compartilhamentos acessíveis para os usuários, como os comandos:

mkdir -p /home/common/public <ENTER>
chgrp nogroup /home/common/public <ENTER>
chmod 0770 /home/common/public <ENTER>

Essa seria a pasta pública, acessível a todos os usuários. Vamos então inserir no smb.conf as configurações de compartilhamento:

 
Se você quiser a opção de criar uma reciclagem dos itens eventualmente apagados pelos usuários, pode inserir as configurações abaixo no arquivo smb.conf, caso contrário basta não fazer esta parte:


Salve o arquivo e feche-o. Vamos testar agora a configuração, digitando:

testparm <ENTER>


Veja que, no nosso exemplo, o nome do servidor ficou muito grande, deve ter no máximo 15 caracteres, então vou mudar o nome para servidor-1 e isso deve ser feito nos arquivos hosts e hostname. Não é preciso fazer no smb.conf. Uma vez reiniciada a máquina depois dessa mudança ou mesmo se estiver tudo certo, basta digitar:

systemctl restart smbd <ENTER>
systemctl restart nmbd <ENTER>

Pronto, servidor funcionando. Para acessar no Windows, basta ir no Explorer na parte de redes e clicar no servidor; se ele não aparecer, basta digitar no campo de pesquisa por:

\\servidor-1 <ENTER>


Agora basta digitar o usuário e senha lá do servidor e pronto.


Você verá duas pastas, uma "public" e outra do usuário, sendo que a public todos a acessam e a do usuário apenas ele. Veja que essa pasta não é a mesma pessoal que o usuário tem no servidor, é uma pasta de rede, onde uma (com o nome dele) apenas o usuário em questão acessa e a public onde todos os usuários com as permissões acessam. Note que você poderá mapear esse compartilhamento como uma unidade de rede (botão direito, mapear unidade de rede) e a terá disponível sempre que a máquina entrar, uma boa opção para o usuário onde só ele utiliza a sua máquina.

No MacOS é basicamente a mesma coisa, basta clicar no Finder, lado esquerdo, em Rede:


Clicando no servidor, vá lá em cima, lado direito, em Conectar Como e escolha o usuário desejado:
Clique em Conectar e pronto.


No Linux, basta abrir o navegador de arquivos, ir em Redes ou Outros Locais ou mesmo Conectar ao Servidor (dependendo do navegador de arquivos) e clique no compartilhamento desejado:


e depois digite o usuário desejado:



Então é isso. Vale lembrar que a pasta Public é casa da mãe Joana, todo mundo pode botar e tirar o que quiser, independente de quem tenha colocado algo lá. Desse modo o Xupeta pode encher de arquivos MP3 e o Goiaba pode apagar tudo, mas as pastas de rede individuais de cada usuário apenas o usuário logado pode acessar. Em um próximo post vamos ver como implementar grupos e permissões de usuários para que isso seja evitado.


quinta-feira, 2 de julho de 2020

LTSP no Debian 10 - Duas placas de rede

LTSP no Debian 10 - Duas placas de rede

Já vimos aqui neste blog como fazer o LTSP funcionar no Debian 8, 9 e 10 e no UBuntu 16.04 e 18.04 mas todos eles foram em relação ao servidor usar apenas uma placa de rede, onde a rede seria assim:


Agora vamos ver como implementar o LTSP no Debian 10 com o servidor usando duas placas de rede, uma para a internet e outra para a rede local. Infelizmente o tutorial do Wiki do Debian para o LTSP com duas placas de rede não funciona, então posto aqui como fazê-lo. O ambiente seria mais ou menos assim:


Esse arranjo pode ser usado em instalações onde não se quer que os IPs das máquinas clientes sejam os mesmos das demais máquinas da rede, usando-se então um switch à parte apenas para as máquinas LTSP ou então VLans para diferenciar as redes entre si ou alguma outra configuração de rede onde se queira separar as máquinas umas das outras.

A configuração do LTSP com duas placas de rede é basicamente é a mesma coisa para o LTSP com apenas uma placa de rede, mas vou fazer o tutorial completo. O post relativo a essa configuração do Debian 10 com uma placa de rede pode ser visto aqui.

O servidor então precisa ter duas placas de rede, uma para a internet e outra para a rede local. A placa de rede de internet deve ser ligada ao modem roteador ou ao equipamento de rede que provê internet para a rede e a placa de rede local deverá ser ligada ao switch onde as máquinas LTSP estarão ligadas. A interface de rede de internet (no nosso exemplo, a rede WAN) deverá ser colocada em DHCP; já a placa de rede local deverá ter a sua configuração IPV4 como manual, com o IP 192.168.67.1 e máscara de subrede 255.255.255.0. Não é necessário colocar nada em Gateway.


Salve a configuração. Depois disso, instale tudo que você precisar de programas, scripts e atualização de sistema que você vai usar na sua rede, assim dará menos trabalho para fazer o ambiente LTSP mais tarde. Instalado tudo e reiniciado o servidor, vamos instalar os pacotes necessários, tudo como root:

apt-get install dnsmasq ltsp-server-standalone epoptes epoptes-client ltsp-client network-manager-gnome dnsutils rsync <ENTER>

Após a instalação desses pacotes, devemos criar o usuário do servidor e colocá-lo no grupo "epoptes". Pode ser tanto o próprio usuário criado na instalação do servidor quanto a criação de outro específico. No caso vou optar por um específico:

adduser administrador <ENTER>

Defina a senha, o resto pode ser na base do "enter" e finalize a criação do usuário depois da pergunta "os dados estão corretos?". Criado o usuário, vamos então colocá-lo no grupo "epoptes":

usermod -G epoptes -a administrador <ENTER>

Se o grupo não existir, crie-o e depois adicione o usuário a esse grupo com o comando acima:

addgroup epoptes <ENTER>

Vamos criar então o arquivo de configuração do dnsmasq:

ltsp-config dnsmasq <ENTER>

Abra o arquivo ltsp-server-dnsmasq.conf para vermos algumas configurações:

nano /etc/dnsmasq.d/ltsp-server-dnsmasq.conf <ENTER>

Procure no arquivo por "dhcp-range=..., proxy" e veja se o endereço da rede da sua rede dada pelo dhcp do seu roteador está lá (no nosso cenário, é 192.168.3.0):


Se não estiver, mude de acordo com o gateway de internet da sua rede. Se em vez do roteador você usar uma máquina PfSense, basta colocar ali o endereço da rede da placa de rede local. Por exemplo, se a placa de rede local do PfSense tiver o endereço IP 192.168.100.1, então essas linha deverá ficar:

dhcp-range=192.168.100.0,proxy

Atenção agora à linha "dhcp-range=---,8h":

#dhcp-range=192.168.67.20, 192.168.67.250,8h

Tire o "#" do início da linha pois agora vamos usar o dnsmasq para gerenciar o dhcp da rede LTSP. Note que as duas linhas "dhcp-range" estão habilitadas, sem o # no início de suas linhas. Não mude o range de IPs já pré-configurado pois essa linha também aparece em outros arquivos de configuração do LTSP e, se mudar no dnsmasq, será necessário também mudar nesses outros lugares (exemplo abaixo):


Salve o arquivo e agora vamos criar o ambiente LTSP:

ltsp-update-image --cleanup / <ENTER>

Aguarde que isso vai levar um certo tempo. Agora vamos criar o arquivo de configuração para as máquinas clientes:

ltsp-config lts.conf <ENTER>

E instale o seguinte pacote:

apt-get install nfs-kernel-server <ENTER>

Criamos o arquivo de exportação:

ltsp-config nfs <ENTER>

Apagamos o link simbólico criado:

rm -iv /var/lib/tftpboot/ltsp/amd64/pxelinux.cfg/default <ENTER>

e criamos o arquivo real do link simbólico anterior:

nano /var/lib/tftpboot/ltsp/amd64/pxelinux.cfg/default <ENTER>

Coloque as seguintes linhas no arquivo:

default ltsp-NFS
ontimeout ltsp-NFS
label ltsp-NFS
menu label LTSP, using NFS
kernel vmlinuz-amd64
append ro initrd=initrd.img-amd64 init=/sbin/init-ltsp forcepae root=/dev/nfs nfsroot=/opt/ltsp/images ltsploop=amd64.img
ipappend 3

Atenção que o que está em vermelho é tudo em uma linha só. Salve o arquivo, reinicie o servidor e teste a sua rede LTSP no Debian 10. Lembrando que toda e qualquer mudança no servidor em relação à instalação ou remoção de programas, atualização de sistema e tal será necessário criar a imagem do LTSP com as mudanças usando o comando:

ltsp-update-image --cleanup / <ENTER>

Veja que mesmo que a rede LTSP nessa fase da instalação esteja funcionando, a internet nas máquinas clientes não estará, então vamos criar alguns arquivos para que a mesma seja habilitada no boot do servidor. No Terminal como root, digite:

nano /usr/bin/internet.sh <ENTER>

Coloque o seguinte conteúdo:

#!/bin/bash
iptables -F
iptables -t nat -F
modprobe iptable_nat
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o enp0s3 -j MASQUERADE
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT


Atenção que a penúltima linha, o que está em vermelho deve ser a interface de rede de internet do servidor e não a de rede local. No nosso cenário, a interface enp0s3 é a de internet e a enp0s8 é a de rede local.


Salve o arquivo e dê permissão de execução:

chmod a+x /usr/bin/internet.sh <ENTER>

Para ativar a internet manualmente, basta digitar no Terminal como root:

internet.sh <ENTER>

Para ativar a internet sempre que ligar o servidor, vamos criar o serviço que vai ser habilitado no boot. Digite como root:

cd /etc/systemd/system <ENTER>

nano internet.service <ENTER>


Coloque o seguinte conteúdo:


#!/bin/bash


[Unit]

Description=Internet

After=multi-user.target

[Service]

Type=simple

ExecStart=/usr/bin/internet.sh start

User=root

WorkingDirectory=/usr/bin

Restart=no

[Install]

WantedBy=multi-user.target


Salve o arquivo. Agora vamos dar permissões ao arquivo:


chmod 755 internet.service <ENTER>


Agora vamos habilitar o serviço:


systemctl enable internet.service <ENTER>

systemctl daemon-reload <ENTER>


Iniciar o serviço:


systemctl start internet.service <ENTER>


Ver se o serviço está rodando:


systemctl status internet.service <ENTER>



Agora basta reinicia o servidor e a internet será habilitada no LTSP automaticamente. Se você colocar máquinas comuns com sistema já pré-instalado (Linux, MacOS ou Windows) no switch das máquinas LTSP, essas máquinas irão pegar IP da rede LTSP porém não vão navegar na internet; para permitir isso, basta editar as configurações de rede dessas máquinas "intrusas" e colocar em DNS o endereço do seu roteador, ou PfSense ou mesmo o do Google, 8.8.8.8.

domingo, 28 de junho de 2020

LTSP no Debian 10

LTSP no Debian 10

Aqui no blog já fiz tutoriais de como implementar o LTSP no Ubuntu 16, Ubuntu 18, Debian 8, Debian 9 e agora vou mostrar como fazer no Debian 10. É um saco os desenvolvedores ficarem mudando a forma de fazer vertas coisas sendo que elas funcionam direitinho na versão anterior do sistema e depois muda radicalmente na nova versão, mas deixa pra lá. Esse tutorial foi feito a partir do wiki do Debian nesse endereço. Qualquer erro na sua instalação, procure nesse link a solução já que enxuguei ao máximo esse tutorial.

Nosso cenário é uma rede com um servidor com uma placa de rede ligada a um switch junto com as máquinas do LTSP e um modem roteador ou um equipamento tipo PfSense para gerenciar o dhcp, conforme a imagem abaixo:


Com a máquina já com o Debian 10 instalado junto com uma interface gráfica (caso deseje), instale todos os programas que a sua rede vai precisar para o uso do dia a dia (programas multimídia, navegadores de internet, ferramentas de programação, etc) e atualize o sistema. Depois de reiniciar a máquina, vamos instalar alguns pacotes (modo root):

apt-get install dnsmasq ltsp-server-standalone epoptes epoptes-client ltsp-client network-manager-gnome dnsutils rsync <ENTER>

Após a instalação desses pacotes, devemos criar o usuário do servidor e colocá-lo no grupo "epoptes". Pode ser tanto o próprio usuário criado na instalação do servidor quanto a criação de outro específico. No caso vou optar por um específico:

adduser administrador <ENTER>

Defina a senha, o resto pode ser na base do "enter" e finalize a criação do usuário depois da pergunta "os dados estão corretos?". Criado o usuário, vamos então colocá-lo no grupo "epoptes":

usermod -G epoptes -a administrador <ENTER>

Se o grupo não existir, crie-o e depois adicione o usuário a esse grupo com o comando acima:

addgroup epoptes <ENTER>

Não vamos mexer no arquivo /etc/network/interfaces e nem na interface de rede, nosso cenário será o mais simples possível. As configurações presentes na atual instalação do sistema deverão funcionar sem problemas. Vamos criar então o arquivo de configuração do dnsmasq:

ltsp-config dnsmasq <ENTER>

Abra o arquivo ltsp-server-dnsmasq.conf para vermos algumas configurações:

nano /etc/dnsmasq.d/ltsp-server-dnsmasq.conf <ENTER>

Procure no arquivo por "dhcp-range=..., proxy" e veja se o endereço da rede da sua rede dada pelo dhcp do seu roteador está lá (no nosso cenário, é 192.168.3.0):


Se não for, mude-o conforme a necessidade. Se em vez do dhcp do roteador você tiver uma máquina com PfSense com duas placas de rede, uma que recebe a internet e outra que a distribui, você deverá configurar o item "dhcp-range=..., proxy" para a rede da placa que distribui a internet na sua rede com o IP da rede dessa placa. Por exemplo, se o IP de rede dessa placa for 192.168.100.1, então você deverá deixar assim:

dhcp-range=192.168.100.0, proxy

Nesta configuração (tanto via roteador quanto via PfSense), as máquinas clientes receberão os IPs dentro da faixa de IPs dada pelo roteador ou pelo PfSense; então você deve optar por uma ou outra. 

Veja que usar uma máquina PfSense para gerenciar a rede é mais interessante pois a maioria dos roteadores baratos de internet vendidos e usados por aí não conseguem lidar com muitas requisições de IP e acabam travando, ou reiniciando ou impedindo que outros IPs sejam atribuídos caso chegue ao limite de fornecimentos de IP. Por exemplo, o switch sem fio D-Link 520 só consegue lidar com 16 conexões de IP (só um exemplo já que no LTSP não se usa rede sem fio para conectar as máquinas clientes).

Depois disso, reinicie o serviço do dnsmasq:

systemctl restart dnsmasq.service <ENTER>

Vamos criar agora o ambiente LTSP:

ltsp-update-image --cleanup / <ENTER>

Aguarde que isso vai levar um certo tempo. Agora vamos criar o arquivo de configuração para as máquinas clientes:

ltsp-config lts.conf <ENTER>

E também o seguinte pacote:

apt-get install nfs-kernel-server <ENTER>

Criamos o arquivo de exportação:

ltsp-config nfs <ENTER>

Apagamos o link simbólico criado:

rm -iv /var/lib/tftpboot/ltsp/amd64/pxelinux.cfg/default <ENTER>

e criamos o arquivo real do link simbólico anterior:

nano /var/lib/tftpboot/ltsp/amd64/pxelinux.cfg/default <ENTER>

Coloque as seguintes linhas no arquivo:

default ltsp-NFS
ontimeout ltsp-NFS
label ltsp-NFS
menu label LTSP, using NFS
kernel vmlinuz-amd64
append ro initrd=initrd.img-amd64 init=/sbin/init-ltsp forcepae root=/dev/nfs nfsroot=/opt/ltsp/images ltsploop=amd64.img
ipappend 3

Atenção que o que está em vermelho é tudo em uma linha só. Salve o arquivo, reinicie o servidor e teste a sua rede LTSP no Debian 10. Lembrando que toda e qualquer mudança no servidor em relação à instalação ou remoção de programas, atualização de sistema e tal será necessário criar a imagem do LTSP com as mudanças usando o comando:

ltsp-update-image --cleanup / <ENTER>

É interessante dar uma olhada no arquivo lts.conf caso você queira personalizar algumas configurações nas estações, mas aí é com vocês...