Aqui fica para download.

Para quem não usa a função de “hibernar” em máquinas virtuais, pode muito desactivá-la, e consegue libertar no disco, o valor da memória.

Por exemplo, uma máquina virtual com 2GB de RAM, ao desactivar o hibernate, liberta em disco 2GB, sem necessidade de reboot sequer.

Para fazer isto, abrir uma consola de DOS em modo de administrador (obrigatóriamente como Administrador), e escrever “powercfg -h off”, seguido de ENTER.

NOTA: deixam de poder hibernar a máquina virtual, mas conseguem reduzir o espaço utilizado.

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.

Numa janela de dos, executando isso conseguimos ver o que temos na cache, e claro, para limpar tudo


ipconfig /flushdns


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.

Um pouco por todo o mundo fizeram-se sentir hoje quebras no acesso a alguns serviços do Google. Eu por cá notei falhas através de vários operadores, e pelo que pude averiguar (ver imagem) quem não teve sem acesso mesmo, esteve pelo menos com latências muito altas.

Segundo o blog da ZDNET em http://blogs.zdnet.com/BTL/?p=18064 parece que várias zonas dos EUA foram afectadas, perdendo mesmo o acesso ao GMAIL e ao Calendar durante várias horas.

Encontrei ainda posts de pessoas que estavam em pânico porque o email deles estava todo lá, e não conseguiam contactar ninguém do Google. Curiosamente, ainda esta semana tivemos um cliente que nos comprou serviço de alojamento para o site da empresa dele, mas optou por deixar o email no GMAIL, por ser mais “fidedigno”. Será que mantém a mesma opinião?


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

1º Abrir a porta 21

netsh advfirewall firewall add rule name="FTP (no SSL)" action=allow protocol=TCP dir=in localport=21


2º Activar a regra para a aplicação de FTP (aka Stateful FTP) que irá abrir as ligações dinâmicas

netsh advfirewall set global StatefulFtp enable


Já agora, 2 links interessantes:

• Configuring FTP Firewall Settings
• FTP7 for Windows Server 2008 RTM is released!

Isto para mim são boas notícias! Talvez a melhor de 2008. Depois de um mês atribulado (que ainda não acabou) a lutar com o upgrade de HELM3 para HELM4 sinto que falta no mercado do alojamento partilhado um painel de controlo para Windows com estabilidade e segurança.

Na WL usamos o HELM desde que começamos a comercializar alojamento windows (já lá vão 4 anos) e apesar de alguns problemas (normais em todos os softwares deste género), sempre se foi aguentando e sempre foi do agrado dos clientes. A versão 3 tinha uma limitação muito grande na nossa opinião que era o problema de não controlar quotas nem tráfego. Se o cliente ultrapassasse o espaço e/ou tráfego contratado ele enviava um email a avisar (na verificação diária que fazia). Ou seja, de madrugada quem estava a abusar, recebia um email de aviso e nós também.

Com 10 ou 20 contas de alojamento, isto controla-se muito bem… mas quando passamos de dezenas para centenas de domínios, a coisa complica-se. Este foi o ponto que nos fez mudar para HELM4. O buzz sobre a versão 4 deste software foi imenso, uma campanha de marketing tremenda que criou expectactivas muito altas, para algo tão “verde” ainda.

A nossa experênica com o cPanel é ainda mais antiga, desde que entramos neste negócio (2001/2002). Desde essa altura o software sempre se mostrou estável, com uma evolução muito razoável e bem pensado para o negócio em que opera. Vamos lá ver como se vão safar com esta versão Windows. Eles dizem que o desenvolvimento da versão para Linux não se vai ressentir, assim espero.