Linux num MacMini

Tinha um MacMini PPC, disco de 80 Gb, 1 Gb de RAM, parado em cima da minha secretária. Precisava de uma máquina para as minhas brincadeiras e testes. Procurei informação, e descobri que sem muito trabalho era possível ter o Ubuntu Server a correr nesta máquina.

Download da ISO do site, gravei o CD.. et voila!

Linux server 2.6.31-14-powerpc #48-Ubuntu Fri Oct 16 14:11:44 UTC 2009 ppc

A versão mais recente que encontrei para download da ISO foi a 8.04. Instalei essa, e depois meia dúzia de apt-get’s… e está feito: Ubuntu 9.10 Server, up & running.

Confesso que sou um utilizador de linuxes com sabor REDHAT desde 1996, e o processo de habituação ao apt-get, entre outras coisas vais ser complicado, mas a essência é a mesma.

Migrar containers dentro entre hosts distintos

Temos um cliente com uma máquina antiga, que tem 10 VPS a correr num servidor CentOS com OpenVZ, e necessitava de migrar para uma máquina nova esses containers. Tive que explorar, e descobri que é um processo até bastante simples.

Numa primeira fase, que não tem a ver com o openvz em si, temos que configurar o acesso do servidor antigo ao novo, sem ser necessário password. Isso é simples, usando ssh keys. Ultrapassada essa fase (ou seja, fazendo ssh servidor_novo a partir do antigo, e ele ligar-se directamente sem pedir password), basta usar o vzmigrate. É possível até fazer a migração sem grande downtime, usando o comando
vzmigrate --online 10.0.0.1 120 Em que 10.0.0.1 é o IP do servidor de destino, e 120 é o CID.

A partir daqui:

OPT:--online
OPT:10.0.0.2
Starting online migration of CT 120 to 10.0.0.1
Preparing remote node
Initializing remote quota
Syncing private
Live migrating container...
Syncing 2nd level quota
Cleanup

E pronto, se fizermos “vzlist -a” no servidor antigo, veremos que o container já não está lá. E o mesmo comando no servidor novo, mostra-nos o container a correr. Se durante o processo pingar-mos o IP do container, o downtime é praticamente nulo.

Nota: Isto funcionou tudo muito bem, para containers centos, dentro de um host centos também, e com menos de 12Gb. Ao copiar um de 19Gb o container foi para o servidor novo, mas simplesmente não o consegui eliminar do antigo. E tive que o arrancar no novo.

Configurar SSH keys

Short version:

Na vossa máquina, executar:
ssh-keygen -t dsa

Vai gerar a key, e pedir uma passphrase, definam uma ou carreguem no ENTER para continuar. (Convém definir uma)

Dentro da vossa home, vai ser criada uma directoria com o nome .ssh/ e lá dentro vários ficheiros. Devem copiar o conteúdo do ficheiro id_dsa.pub, para o servidor de destino, para dentro de um ficheiro chamado authorized_keys2
scp ~/.ssh/id_dsa.pub servidordestino:.ssh/authorized_keys2

Pronto, agora basta fazer ssh servidordestino e colocar a passphrase.

Review Linux2009

Foi no passado dia 24 de Setembro, em Lisboa o evento LINUX2009 – VII Encontro Nacional sobre Tecnologia Aberta, organizado pela Caixamágica e Sybase.

Fui até lá com um amigo, e no geral não desgostei.

A versão longa das coisas, pode ser vista aqui. Eu escrevo apenas a minha opinião resumida:
- Microsoft, mais valia não estarem presentes. Quando lhes falam que a implementação que fizeram dos standards não foi bem feita, o senhor que os representava teve a lata de dizer “obrigaram-nos a fazer, nós fizemos, agora não está bem feito, ainda temos muito que trabalhar”. Ora bem, quando estes artistas simplesmente não conseguiram no caso do Excel, fazer com que um documento que tenha uma fórmula com um simples somatório, fique com a fórmula, simplesmente importa o resultado final. Dá-me vontade de lhe responder: “estão aqui 2 batatas cruas, isto vai ser o seu almoço. Já é um começo, é dali que vai sair um belo puré daqui a algum tempo, não me pode é pedir tudo duma vez”.

- Novell, bem aqui consigo ser mais dramático e apelidá-los de “Microsoft biatchs!” Nítidamente venderam-se à Microsoft. Aliás, não se venderem, a Microsoft é que os salvou de se afundarem de vez, e injectou lá alguma “saúde”, por isso os senhores estavam a fazer o papel deles, e não podiam cuspir no prato que lhes dá de comer.

- Scalix, o rapazinho tem jeito, e gostei do que vi.

- Redhat. Ok, ele é nitidamente um evangelista, e tem jeito para o trabalho dele, mas um bocadinho menos de palhaçada não lhe ficava mal.

Quanto à organização. Atrasos, desculpas pelos atrasos, e mais atrasos. Mesmo atrasados, não via muita preocupação dos organizadores e intervenientes em restabelecer a normalidade.

Por último as coolsessions, se calhar eu é que ia com uma ideia errada, e pensava que se ia pôr “as mãos na massa” mas afinal parecia o intervalo das novelas na TVI carregadinho de publicidade. Aliás, não se davam casos concretos, nem se viam detalhes, pelo menos nas sessões que vi, foram apresentações comerciais, e um bocadinho de nada narcizistas.

Ligação VPN no CentOS

Instalei recentemente no meu desktop o CentOS 5.3 com o KDE.

Já há algum tempo que não usava o Linux no Desktop, apesar de diáriamente o usar, em grande parte do meu tempo, mas sempre por ligação a máquinas que não possuem ambiente gráfico.

Assim que terminei a instalação, primeiro ponto que precisei foram os drivers da NVIDIA, mudar runlevel, instalar os pacotes do kernel necessários e o gcc (atenção ao kernel que estão a usar, porque no meu caso estou a usar o kernel-PAE e por isso tive que instalar o kernel-PAE-devel), e ficaram instalados.

Próximo passo, que preciso MESMO de ter, é ligação à VPN da empresa. E isso sim, pensei que já estaria mais simplificado, ou que já haveriam GUI para tudo e mais alguma coisa. Pelos vistos enganei-me. Ainda tem que ser tudo “à mão”, e na consola.

Encontrei este artigo, que ensina tudo. E depois de o seguir, configurar o routing e… pimba, já está!

Já faltava um interface bonitinho e simples para configurar a ligação VPN, ou há e eu é que não encontrei?

Activar acesso SSH no VMware ESXi

Para activar o acesso SSH (eu precisei logo para poder fazer o wget de umas ISO’s), basta seguirem o seguinte:

  1. Aceder à consola, e carregar em ALT+F1 para abrir uma consola
  2. Escrever unsupported na janela que vos abre, e carregar ENTER
  3. Aparece um ecran que pede a password, colocar a password, e novamente ENTER
  4. Editar o ficheiro inetd.conf (vi /etc/inetd.conf)
  5. Na linha que começa por # SSH, retirar o #
  6. Gravar o ficheiro
  7. Matar o processo inetd ( executar primeiro “ps | grep inetd” para saber qual o PID do processo, e depois “kill -HUP _PID_” )

E pronto, basta isto.

Adicionar um 2º IP à mesma placa em linux

Este procedimento apenas poderá ser executado, com permissões de root na máquina, mas é um processo simples. Acedendo por SSH, fazer o seguinte:

1. Aceder à directoria que contém as configurações da rede
cd /etc/sysconfig/network-scripts
2. Verificar quais os adaptadores de rede existentes
ls ifcfg-*
3. Copiar as configurações do interface actual para um novo interface (virtual)
cp ifcfg-eth0 ifcfg-eth0:0
4. Editar o novo interface, alterando as informações para o novo IP
vim eth0:0
Nota: alterar obrigatoriamente as variáveis DEVICE (para eth0:0) e IPADDR (para o novo IP)

5. Activar o novo interface

ifup eth0:0
E pronto, já deve responder.

How to change date/timezone on vps

If your container was wrong date/timezone, login to the host node and run


$ vzctl stop 110
$ vzctl set 110 --capability sys_time:on --save
$ vzctl start 110


After that, just login in the container:


$ vzctl enter 110


And do this:


$ mv /etc/localtime /etc/localtime.old
$ ln -s /usr/share/zoneinfo/Europe/Lisbon /etc/localtime


That’s it!

Desactivar core dumps no linux (centos/redhat/fedora)

Sempre que em ambientes linux uma aplicação/daemon “crasha”, por defeito o sistema cria ficheiros enormes com dumps de memória com o nome de “core.xx” em que xx representa o id do processo.

Se não forem monitorizados, estes ficheiros podem ocupar rapidamente bastante espaço. Caso não tenhamos intenção de fazer debug ao problema é aconselhável que se desactive a criação destes dumps de forma a poupar espaço.

Para desactivar este core dumps em sistemas redhat e derivados (centos, fedora, etc) basta editar o ficheiro /etc/security/limits.conf e teremos qualquer coisa como


...
#* soft core 0
#* hard rss 10000
#@student hard nproc 20
...

basta tirar o comentário na linha


* soft core 0

Com esta alteração alteramos o limite para os core dumps para 0, ou seja não são feitos sequer.