Script para coletar informações básicas da máquina

Coleta informações como hostname, modelo e quantidade de CPU, memória, disco e rede.

A parte de coleta de informações de rede foi baseada no script disponibilizado no Viva o Linux [1].

O script ficou meio grande para colocar aqui no post, então segue um trechinho do código… e no arquivo info_maquina.doc consta o script completo.

#!/bin/bash
#### Script para coletar informacoes da maquina
## Nix - Novembro/2013
# Coleta info de memoria
MEM="$(cat /proc/meminfo | grep "\MemTotal" | cut -d\: -f2-)"
MEM="$(echo ${MEM})"
# Coleta info processador - quantidade
NPROC="$(cat /proc/cpuinfo | grep -i processor | wc -l)"
NPROC="$(echo ${NPROC})"
# Coleta info processador - modelo
PROC="$(cat /proc/cpuinfo | grep "\model name" | tail -1 | cut -d\: -f2-)"
PROC="$(echo ${PROC})"

Saída na tela:

Saída informações da máquinas
Saída informações da máquinas

Referência:

[1] Script simples para pegar informações sobre a placa de rede

Anúncios

Script para validação de senhas em massa

Estreando uma nova categoria dentro de Learning no blog: Scripts.

Não… não sou programadora… mas quem administra sistemas, desde cedo aprende que quanto mais tarefas rotineiras for possível automatizar… mais tempo terá para fazer coisas interessantes, como por exemplo, iniciar um estudo de uma tecnologia que pode ser utilizada na empresa, ou trabalhar em algum projeto, enfim… ‘n’ coisas :).

Ainda tenho muito o que aprender em termos de script (começando pela lógica :(), mas andei brincando com alguns scripts e descobri que apesar de não saber programar, não é que eles foram de grande ajuda no meu dia-a-dia? 🙂

Mas vamos lá… Recentemente, precisei fazer uma validação em massa da senha de root em vários servidores, sendo que para cada um a senha era diferente.

Com a ajuda do expect [1] e um howto [2] bacana encontrado by google, consegui realizar a validação :).
pwtest.exp
#!/usr/bin/expect -f

################################################################################################################
## Script para testar a conexão com o servidor e checar se a senha do usuário root está correta ou não ##
## Utiliza o comando expect para fazer o acesso e inserir a senha ##
## Referência: http://www.pantz.org/software/expect/expect_examples_and_tips.html ##
## Nix - 23/08/2013 ##
################################################################################################################
######### Variaveis ######### 
set timeout 9
set HOST [lindex $argv 0]
set PASS [lindex $argv 1]
log_user 0

## Inicializa a conexão SSH 
spawn ssh -q -o StrictHostKeyChecking=no root@$HOST
## Mensagem de erro a ser exibida caso ocorra timeout na conexão SSH (prompt que solicita a senha não é exibido)
## *assword é para corresponder "Password" ou "password" :)
expect {
 timeout { send_user "\nFailed to get password prompt\n"; exit 1 }
 eof { send_user "\nSSH failure for $HOST\n"; exit 1 }
 "*assword"
}
## Caso o prompt que solicita a senha é exibido, a mesma é enviada
send "$PASS\r"

## Mensagem a ser exibida caso a senha esteja incorreta
## *\# indica o prompt do usuário - no caso, o root
expect {
 timeout { send_user "$HOST - Login failed. Password incorrect.\n"; exit 1}
 "*\# "
}
## Caso a senha esteja correta, é exibida a mensagem abaixo:
send_user "$HOST - Password is correct\n"

## Desconecta do servidor - o mesmo que Control+D:
send "exit\r"
## Encerra programa
close

==============================================================================================================================
valida_pw.sh
#!/bin/bash

################################################################################################################
## Script para validar senhas em massa a partir de um arquivo de servidores e outro com as respectivas senhas 
## Executa o arquivo pwtest.exp 
## Nix - 23/08/2013
################################################################################################################

######## Variaveis ########
# Lista de servidores
HOSTS=$(cat /root/temp/hosts_dev.txt)
# Arquivo de senhas
PWDS=$(cat /root/temp/pws_dev.txt)

####### Contador para ler o arquivo de senhas linha a linha #######
i=0
for pd in $PWDS; do
 pws[$i]=$pd;
 i=`expr $i + 1`
done

####### Contador para ler o arquivo de hosts linha a linha e testar a senha usando o script expect #######
### É passado como parâmetro o servidor ($j) e a senha do mesmo ($pws)
i=0
for j in $HOSTS; do
 /root/temp/pwtest.exp $j ${pws[$i]}
 i=`expr $i + 1`
done

============================================================================================================================== 

Para executar (antes é necessário dar permissão usando o comando chmod ;)):

$./valida_pw.sh

Até a próxima! 🙂
Referências:
[1] http://www.nist.gov/el/msid/expect.cfm
[2] http://www.pantz.org/software/expect/expect_examples_and_tips.html

SSH – Secure SHell

Muito utilizado em ambientes Unix/Linux, é um sistema de acesso remoto que implementa um serviço similar ao telnet utilizando autenticação criptográfica para confirmar a identidade de um usuário e criptografando todo o fluxo de informações entre dois hosts.

Embora o SSH seja basicamente utilizado para conexão em máquinas remotas e execução de comandos, existem outras funcionalidades como tunelamento, redirecionamento de portas, transferência de arquivos entre outras.

Para garantir segurança em uma comunicação SSH são utilizadas chaves assimétricas compostas pelo par de chaves pública/privada. A chave pública permite encriptar dados enquanto a chave privada permite desencriptar as informações que foram embaralhadas pela chave pública.

Quando criamos um par de chaves, uma será privada e a outra será pública. A chave privada é de sua propriedade e deve ser guardada em segurança; a chave pública deve ser colocada no servidor remoto. Assim, a conexão só será estabelecida se a chave privada se encaixar na chave pública.

Esquema das chaves criptográficas do SSH

Quando se conecta no servidor SSH, o cliente envia sua chave pública e requisita a chave pública do servidor.

Ao receber a chave pública do servidor, o cliente gera uma chave secreta válida para a sessão (chave simétrica), e encripta (a chave secreta) com a chave pública do servidor e envia de volta.

O servidor desencripta a chave secreta, e encripta novamente com a chave pública do cliente enviando a este para confirmação.

Após a confirmação, cliente e servidor estão mutuamente autenticados e trocam os dados criptografados com a chave de sessão.

 

Componentes do servidor SSH

O servidor ssh é composto dos seguintes itens:

Protocolo SSH

  • Define um canal seguro de comunicação.
  • Por padrão, trabalha na porta 22.
  • Existem duas versões (ssh/v1 e ssh/v2).

sshd

  • Daemon do servidor ssh que aceita requisições de clientes SSH, provendo autenticação, privacidade e integridade.

ssh

  • Utilizado no lado cliente, envia requisições ao servidor SSH para abrir a sessão de terminal remoto, transferências de arquivos ou execução de comandos.

Configuração do serviço SSH

Falando na parte de configuração do serviço SSH, antes de tudo é necessário verificar se o pacote está instalado. No Debian e seus derivados o servidor não vem instalado por padrão, então, para checar se temos o pacote:

# dpkg -l | grep ssh
ii  openssh-server                    1:5.1p1-5                  secure shell server, an rshd replacement

Caso não tenha o pacote, para instalar:

# apt-get install openssh-server

Numa instalação básica, o serviço já está pronto para ser utilizado, isto é, o servidor já está pronto para receber conexões. As configurações do ssh ficam armazenadas em /etc/ssh, nesse diretório constam os arquivos para configuração do cliente (ssh_config), servidor (sshd_config), chaves públicas e privadas simétricas e assimétricas além do arquivo moduli que o programa ssh-keygen utiliza para gerar as chaves.

No caso, vamos trabalhar com o arquivo sshd_config:

# cd /etc/ssh

Ahn, sempre que vou mexer em alguma configuração, eu faço um backup do arquivo original… afinal de contas, abençoados sejam os pessimistas, pois ele fizeram backup!

# cp sshd_config /root/backup/sshd_config.ORIGINAL

Acima, só copiei o arquivo sshd_config para o meu diretório de backup com o nome sshd_config.ORIGINAL. Falando sobre as principais linhas do arquivo de configuração:

# vi sshd_config

  • Port 22 – Essa linha indica a porta em que o servidor SSH irá atender as conexões. A porta padrão é a 22, mas podemos mudar esse número para sair do padrão, colocando por exemplo, 1994… aí a linha ficaria assim: Port 1994. No meu caso, estou deixando a porta padrão mesmo.
  • ListenAddress 192.168.0.103 – Essa opção especifca o IP da interface de rede que o servidor SSH irá escutar. O padrão é 0.0.0.0; ou seja escuta em todas interfaces, para melhorar a segurança, limite aqui os endereços das interfaces que o servidor poderá escutar.
  • Protocol 2 –  Versão do protocolo utilizado. Existe a versão 1 e 2; configurar sempre a versão 2 por ser mais segura. Em algumas distros, essa linha pode vir com as duas versões do protocolo, deixar somente uma.
  • KeyRegenerationInterval 3600 – Essa linha indica o tempo (em segundos) para renegociação da chave de sessão.
  • ServerKeyBits 768 – Tamanho da chave. 768 é o padrão
  • LoginGraceTime 120Timeout (em segundos) da conexão SSH caso não haja sucesso no login.
  • PermitRootLogin yes – Habilita o usuário root a fazer login via SSH. Como o root é o super-poderoso administrador da máquina, por questões de segurança, crie um usuário comum para fazer login e depois virar root; sendo assim, altere o valor desse parâmetro para ‘no’.
  • RSAAuthentication yes – Habilita a autenticação através de chave pública. Essa opção só se aplica ao protocolo versão 1.
  • PubkeyAuthentication yes – Habilita a autenticação através de chave pública. Essa opção só se aplica ao protocolo versão 2.
  • PermitEmptyPasswords no – Desabilita a autenticação de usuários sem senha.
  • PasswordAuthentication yes – habilita a autenticação baseada em senha

Após realizar as alterações no sshd-config, bastar salvar o arquivo e reiniciar o serviço:

# /etc/init.d/ssh restart

Checando se o serviço está no ar:

# netstat -antp | grep 22
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      2858/sshd

# fuser -v 22/tcp
USER        PID ACCESS COMMAND
22/tcp:              root       2858 f…. sshd

Com o serviço no ar, é hora de realizar o teste de conexão. E para não haver confusão em quem é cliente e servidor:

  • Servidor SSH – Permite outras máquinas realizarem a conexão.
  • Cliente SSH – Apenas realiza a conexão em uma máquina que tenha o servidor SSH configurado.

Testando a conexão

Existem diversas formas para realizarmos a conexão SSH, a sintaxe do comando para isso é:

# ssh <nome_do_usuário_remoto>@<ip_do_servidor>

No meu ambiente, estou considerando que a máquina 192.168.0.108 é o servidor SSH, e irei utilizar o usuário nixi para estabelecer a conexão remota. A sintaxe do comando acima fica assim:

# ssh nixi@192.168.0.108

No futuro, não aparecerá a mensagem de autencidade do host, como mostrado abaixo (é a primeira conexão que faço para a a máquina 192.168.0.108), porém esse aviso aparece quando o sistema detecta uma diferença na chave pública retornada pelo host remoto e a chave pública que temos. O arquivo que guarda as chaves públicas reside em ~/.ssh/known_hosts (lembrando que ‘~’ significa o diretório home do usuário logado ;)).

Para estabelecer a conexão, basta responder ‘yes‘ (sem as aspas!) e será solicitada a senha do usuário. Após informar a senha, será retornado o prompt do terminal remoto:

# ssh nixi@192.168.0.108
The authenticity of host ‘192.168.0.108 (192.168.0.108)’ can’t be established.
RSA key fingerprint is 8b:51:62:94:52:01:1e:74:d6:8e:7c:b9:39:37:fb:ff.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘192.168.0.108’ (RSA) to the list of known hosts.
nixi@192.168.0.108’s password:
Linux nixi 2.6.26-2-686 #1 SMP Thu Sep 16 19:35:51 UTC 2010 i686

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Feb 18 22:38:39 2011 from 192.168.0.103
nixi@nixi:~$

Acima, acessei como um usuário comum, se for utilizar comandos que necessitam do poder do root, será necessário utilizar o comando su.

Para sair da máquina remota, basta executar o comando logout:

nixi@nixi:~$ logout
Connection to 192.168.0.108 closed.

Outras coisas para fazer com o ssh…

  • Executar comandos remotamente, o usuário faz o login via ssh e depois que o resultado do comando é exibido, a conexão com o servidor é fechada:

$ ssh nixi@192.168.0.108 df -h
nixi@192.168.0.108’s password:
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2             1.3G  110M  1.2G   9% /
tmpfs                  62M     0   62M   0% /lib/init/rw
udev                   10M  652K  9.4M   7% /dev
tmpfs                  62M     0   62M   0% /dev/shm
/dev/sda1             137M   15M  116M  11% /boot
/dev/sda5             942M   18M  877M   2% /home
/dev/sda8             471M   11M  437M   3% /tmp
/dev/sda6             942M  277M  618M  31% /usr
/dev/sda7             471M   85M  362M  19% /var

  • Fazer cópias (download ou upload) de arquivos ou diretórios utilizando o comando scp:

Exemplo de download:

$ scp nixi@192.168.0.108:~/teste_download_nixi.txt /tmp
nixi@192.168.0.108’s password:
teste_download_nixi.txt                       100%    0     0.0KB/s   00:00

$ ls -l /tmp/teste_download_nixi.txt
-rw-r–r– 1 ivani ivani 0 2011-02-20 19:39 /tmp/teste_download_nixi.txt

Apenas copiei o arquivo teste_download_nixi.txt para minha máquina local (lembrando que temos que salvar o arquivo em um diretório que temos permissão de escrita!).

Exemplo de upload:

$ scp teste_nix.txt nixi@192.168.0.108:
nixi@192.168.0.108’s password:
teste_nix.txt                                 100%    0     0.0KB/s   00:00

$ ssh nixi@192.168.0.108 ls -l teste_nix.txt
nixi@192.168.0.108’s password:
-rw-r–r– 1 nixi nixi 0 2011-02-18 23:05 teste_nix.txt

Acima, copiei o arquivo teste_nix.txt para a máquina 192.168.0.108; depois eu chequei remotamente se o arquivo realmente estava lá.

Para copiar diretórios, a sintaxa é praticamente a mesma, com a diferença que temos que acrescentar a opção -r:

Exemplo de download:

Copiar o diretório /root/backup da máquina 192.168.0.108 para o diretório /tmp da minha máquina:

$ scp -r root@192.168.0.108:~/backup /tmp

Exemplo de upload:

Enviar o diretório nixi_bkp para a máquina 192.168.0.108 no diretório /tmp:

$ scp -r nixi_bkp root@192.168.0.108:/tmp/

Depois, conferi remotamente se o diretório estava no servidor remoto:

$ ssh root@192.168.0.108 ls -ld /tmp/nixi_bkp
root@192.168.0.108’s password:
drwxr-xr-x 2 root root 1024 2011-02-18 23:30 /tmp/nixi_bkp

Referências:

Servidor ssh (Foca Linux)

System Administration Toolkit: Set up remote access in UNIX through OpenSSH

Be-a-bá do SSH, parte 1

SSH, The Secure Shell: The Definitive Guide

SSH (Esquema das chaves criptográficas)

Comando sudo

Todo usuário quer ser o administrador da máquina… aquele que manda e desmanda no sistema, instala isso, aquilo e outro… No Linux, o usuário root é o todo super-poderoso administrador da máquina… ele pode tudo!

Entre suas tarefas, estão delegar permissões para o usuários, configurar rede, firewall, desligar a máquina… então, quando estamos conectados ao sistema como root, é bom saber o que estamos fazendo, afinal de contas “grandes poderes trazem grandes responsabilidades”.

Nesse post, vou colocar um exemplo de arquivo de configuração do sudo, que é uma ferramenta que permite que usuários comuns executem um comando como se fosse outro usuário; geralmente tarefas do usuário root.

Através dessa ferramenta, é possível deixar registrado os comandos que determinado usuário executou como root e também as tentativas de acesso. Imagine a seguinte situação: você trabalha em uma equipe e todos utilizam o mesmo login para conectar no sistema. Todo mundo sabe a senha de root, e pode se conectar a qualquer momento. Um determinado dia, alguém conecta como root no sistema e apaga arquivos importantes…

Ok, primeiro vamos tentar consertar o estrago, mas vai ficar no ar a pergunta: “Quem foi?”

Em tempos onde a segurança é fator indispensável nas empresas, é fortemente recomendado que cada usuário que for acessar o sistema, possua o seu login e senha; deve ser configurado no sistema o sudo para auditar os comandos que o usuário executou ou tentou executar, etc.

Outra vantagem em usar o sudo, é que o usuário não precisa saber a senha de root, pois ao executar comandos usando o sudo, ele irá informar a sua senha, e não a senha do usuário root.

Lembrando que o sudo é apenas uma ferramenta… o administrador deve tomar outras medidas de segurança como por exemplo, manter o sistema atualizado, instalar o serviço NTP (Network Time Protocol) para que a data e hora estejam sempre atualizados, garantir que os usuários utilizem senhas fortes e não ‘emprestem’ a senha para terceiros, não grudem um post-it com a senha no monitor… entre outras coisas :D.

Falando sobre a configuração do sudo, essa é feita no arquivo /etc/sudoers. Para editar o arquivo, é utilizado o comando ‘visudo‘. Você pode usar o vi, vim, ou outro editor que lhe agrade… mas existem duas razões para utilizar o comando visudo e não um outro editor de textos:

  1. A edição do arquivo sudoers fica travada para outros usuários – isto é, se você estiver editando o arquivo, evita que outro usuário faça alterações ao mesmo tempo.
  2. O arquivo sudoers tem sua sintaxe; com o visudo você edita com a sintaxe correta, e, se houver algum erro, você será notificado.

Alterações no /etc/sudoers:

# Defaults specification
## Logging – interessante para o sistema registrar de forma organizada os acessos com sudo:
Defaults logfile=/var/log/sudolog

## As opcoes abaixo sao utilizadas para enviar email nos seguintes casos:
## mail_no_user = usuario nao esta na lista do sudo e tenta executar algum comando
## mail_no_perms = usuario esta na lista do sudo e tenta executar algum comando que nao consta na lista
## mail_badpass = usuario esta na lista do sudo e digita a senha incorretamente
## mail_to = email que recebera os alertas

Defaults mail_no_user
Defaults mail_no_perms
Defaults mail_badpass
Defaults mailto = ivani@nix.com.br

## Exigir que o usuário tenha um terminal na máquina e não execute sudo remotamente:
Defaults    requiretty

## Redefine o ambiente para conter somente o LOGNAME, MAIL, SHELL, USER, usuário e as variáveis SUDO_. As demais variáveis no ambiente do usuário que correspondem as que estão na lista de env_keep serão adicionadas.
Defaults    env_reset
Defaults    env_keep = “COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR \
LS_COLORS MAIL PS1 PS2 QTDIR USERNAME \
LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION \
LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC \
LC_PAPER LC_TELEPHONE LC_TIME LC_ALL LANGUAGE LINGUAS \
_XKB_CHARSET XAUTHORITY”

## Lista de usuários que irão utilizar o sudo.
User_Alias      FAMILY = bridap, sheikt, vanap

# Cmnd alias specification
## Lista de comandos que os usuários poderão executar utilizando o sudo
Cmnd_Alias      CM_FAMILY = /usr/bin/apt-get update, /usr/bin/tail -n[0-9]* -f /var/log/*, /usr/bin/crontab -l, /sbin/iptables, /bin/su

# User privilege specification
## Especifica privilegios para um determinado usuário. No caso, foi mantido o próprio root com todos privilégios.
root    ALL=(ALL) ALL

## Especifica privilégios (comando) para usuários que fazem parte da lista GR_CPLEXSUP
GR_FAMILY     ALL=(root)   CM_FAMILY

As configurações acima limitam o usuário executar apenas alguns comandos como root. Uma outra alternativa, é a que é usada pelo Ubuntu. O primeiro usuário cadastrado na máquina, entra no grupo admin… Os demais usuários são comuns… para torná-los administradores, basta inserir os usuários no grupo admin.

A linha para incluir no arquivo sudoers fica assim:

%admin ALL=(ALL) ALL

Comandos interessantes:

  • Listar as permissões de sudo para o usuário logado:

# sudo -l

  • Listar a versão do sudo, opções default e as variáveis de ambiente:

# sudo -V

  • Listar todas opções dispníveis para utilizar com a linha ‘Defaults’:

# sudo -L

Referências:

Instalação do OpenBSD – a saga

Vou falar aqui sobre a instalação do OpenBSD. O projeto OpenBSD desenvolve um sistema operacional do tipo UNIX, disponível livremente, multiplataforma, baseado no 4.4BSD. É focado em correção de falhas, segurança, padronização e portabilidade.

O que vou colocar aqui são algumas anotações… ainda estou aprendendo a mexer com Open… ele é um pouquinho diferente do Linux no que diz respeito a particionamento, instalação. Pensando nisso, lembrei dos tempos que estava começando a aprender a instalar Linux, que eu anotava tudo porque eu não entendia direito os devices, o particionamento (e depois ficava desesperada procurando ‘onde foi que anotei mesmo aquele comando?’)… Então, fiz algumas anotações para instalação do Open e surgiu esse post.

Eu segui a FAQ para fazer a instalação, e aqui vou colocar somente minhas anotações (ou delírios, ainda tenho que ler muito para entender tudo direito).

Minha instalação do OpenBSD é a 4.6 em uma máquina virtualizada; os procedimentos não diferem se for instalar em uma máquina real….

Tipos de instalação

Quando se da o boot com o cd, após a inicialização, nos deparamos com a seguinte questão:

Welcome to the OpenBSD/i386 4.6 installation program.
(I)nstall, (U)pgrade or (S)hell?

Vamos ver o que a  FAQ diz a respeito dessas opções:

Install: Carrega o OpenBSD, sobrescrevendo quaisquer dados que estejam na partição. Note que é possível deixar partições intactas nesse processo, tal como uma /home, mas de qualquer maneira, suponha que tudo mais será sobrescrito.

Upgrade: Instala um novo pacote de arquivos de instalação na máquina, mas não sobrescreve nenhuma configuração, nenhum dado de usuário ou programas adicionais. Nenhuma formatação de disco é realizada, os diretórios /etc e /var não são sobrescritos. Algumas notas importantes:

  • Você não tem a opção de instalar o arquivo etc46.tgz. Depois de instalar, você terá que mesclar manualmente as mudanças de etc46.tgz em seu sistema antes de você considerá-lo completamente funcional. Essa é uma etapa importante que deve ser feita, senão serviços chaves (pf por exemplo) podem não funcionar.
  • O processo de atualização de versão não é projetado para saltar versões! Isso frequentemente funciona, mas não é suportado. Para o OpenBSD 4.6, atualizar do 4.5 para o 4.6 é a única atualização de versão recomendada. Se você quer atualizar uma versão mais antiga, atualize primeiro para as versões intermediárias ou, se o seu sistema está muito desatualizado, considere fazer uma reinstalação completa.

Shell: Às vezes você precisa executar reparos ou fazer a manutenção em um sistema que não inicializa (ou não deve inicializar) um kernel normal. Essa opção permite que você realize a manutenção do seu sistema. Vários utilitários importantes estão disponíveis na mídia de inicialização.

Como e a primeira vez que estou instalando, escolhi a opção I (install).

Informações importantes
Uma coisa que e diferente no Open é a configuração das interfaces de rede. Enquanto no Linux temos os eth* da vida, no Open, as interfaces são nomeadas pelo nome do drive delas. Por exemplo… vic0 é o nome do driver do meu dispositivo de rede na vmware. Se eu tivesse mais uma interface, a próxima seria vic1 e por aí vai. Uma leitura no capítulo 6 da FAQ ajuda com maiores detalhes sobre a configuração de rede no OpenBSD.

Particionamento
O particionamento do OpenBSD sempre me assustou porque eu não tinha entendido ainda como funcionava a separação dos discos. Nem sempre podemos usar o disco inteiro para um SO, e eu queria muito aprender como particionava o HD corretamente; para isso, li o capítulo que fala sobre o particionamento.

E descobri que o particionamento é muito simples… temos apenas que entender que a configuração do disco é feita em duas etapas:

1) Definir uma parte do disco que será usada pelo OpenBSD com o fdisk;

2) Na parte destinada ao OpenBSD, editamos o que é chamado de disklabel, isto e, onde finalmente definimos as partições (/, /home, etc) que irão compor nosso SO.

Fiz um desenho para ilustrar:

HD particionado com fdisk

Disklabel do openbsd

O fdisk do openbsd também é diferente do fdisk do Linux. Alguns comandos importantes que utilizei enquanto estava particionando:

p – mostra as partições existentes (é o mesmo print do fdisk do Linux).

e id – edita uma partição. Por exemplo: e 0 irá definir o tamanho do disco que será usado para o openbsd. Depois que define o tamanho, é necessário especificar qual será o tipo de partição será criada (ntfs, linux native…). No caso, o tipo utilizado para o openbsd é o A6.

update – escreve a partição no disco; isto é ‘assina’ a partição na MBR.

f id – define uma partição como ativa. Exemplo: f 0 define a partição 0 como ativa.

Checklist do particionamento:

  • A assinatura na MBR e válida? Isto e, a partição foi escrita na MBR com o comando update?
  • A partição destinada ao OpenBSD esta marcada como A6? Foi utilizado o comando ‘e id’ para definir o tipo da partição?
  • A partição destinada ao OpenBSD esta ativa? Foi utilizado o comando ‘f id’ para ativar a partição?

Escolhendo os pacotes a serem instalados

Fiz uma leitura saltitante na FAQ sobre como escolher os pacotes que serão instalados.

Por padrão, o openbsd seleciona alguns pacotes para instalar. No caso, veio selecionado games, pacotes para configuração do X, etc. Eu não espero rodar o X no momento e o pacote de games não vai ser interessante; pelo menos não enquanto eu não estiver craque no uso do open :P; sendo assim, desmarquei os pacotes que não queria instalar.

Após a instalação dos pacotes, a instalação foi concluída. Levei umas 3 horas lendo, instalando e reinstalando… mas o resultado foi positivo. Consegui fazer uma instalação sem maiores traumas.

Depois da instalação…

Após o primeiro boot (tudo muito emocionante), fiz alguns procedimentos importantes:

  • Adicionei um usuário comum para executar as tarefas e usar o root somente quando necessário. O comando adduser do openbsd so falta perguntar o tipo sanguíneo :P.

# adduser ivani

  • Instalei os pacotes do bash (o shell padrão do openbsd é o ksh, mas eu prefiro o bash) e o vim (não vivo mais sem ele). Fiz uma leitura do man do comando pkg_add para saber como instalar pacotes:

# export PKG_PATH=”ftp://ftp.openbsd.org/pub/OpenBSD/4.6/packages/i386/”

# pkg_add bash

# pkg_add vim
Ambiguous: vim could be vim-7.2.190p1-gtk2 vim-7.2.190p1-no_x11

Tem vim para ambientes X11 e noX11. Escolhi o noX11:

# pkg_add vim-7.2.190p1-no_x11

Olha o screenshot do meu openbsd:

 

Meu openbsd na vmware

Meus próximos to do’s (não sei quando vou postar o que andei fazendo, mas…):

  • Aplicar patches no OpenBSD
  • Compilar kernel
  • Aprender o pf (packet filter, o firewall do openbsd)
  • Entender o protocolo CARP (Common Address Redundacy Protocol)
  • E mais…

Bom, nesse post, fico por aqui. Até a próxima!