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.

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.

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.

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.

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?

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.

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.


$ 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!

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.