Thursday, February 5, 2009

Erro do AJAX .Net no Internet Explorer, comédia!

Bem que o IE é uma porcaria todo mundo sabe. Tirando a lentidão do coitado ainda é cheio de bugs, e cá vai mais um.

Em aplicações .Net ASPX com AJAX, pode acontecer de algum sortudo ter o seguinte erro de JavaScript após algum tempo de execução:

Sys.WebForms.PageRequestManagerParserErrorException: The message received from the server could not be parsed. Common causes for this error are when the response is modified by calls to Response.Write(), response filters, HttpModules, or server trace is enabled.
Details: Error parsing near '


E o melhor deste erro é que só acontece no IE, no Firefox funciona sempre perfeitamente. Basicamente um problema exclusivo do IE, ainda não sei por que não colocam o Firefox nas empresas, a desculpa de que não é corporativo não cola.

Para resolver isto a "melhor" maneira para o usuário é, limpar os arquivos temporários e reiniciar o browser :D

Andei procurando a algumas semanas uma solução para isto e a única que me ajudou foi neste link, lá em baixo:

http://weblogs.asp.net/leftslipper/archive/2007/02/26/sys-webforms-pagerequestmanagerparsererrorexception-what-it-is-and-how-to-avoid-it.aspx#6815054

# re: Sys.WebForms.PageRequestManagerParserErrorException - what it is and how to avoid it
Friday, January 02, 2009 1:20 PM by Arjan Douwes
I am experiencing the same issue with my Ajax.net website. After adding <customErrors mode="Off"/> to the web.config file at the problem seems to be that the site is being hosted on a webfarm and the SessionState is being encrypted using the MAC Address. The issue with webfarms is that the EnableViewStateMac is by default set to True which causes problems.
In the web.config I changed the <Page> tag to <Page EnableViewStateMac="False">
I also added
EnableEventValidation="false" EnableViewStateMac="false"
to the <%@ Page ... directive of the aspx pages.
These two changes to the website solved my issue.


Ou seja, mudar no web.config o customErrors:


<customErrors mode="Off"/>


E colocar nos ASPX que trabalham com AJAX:


<%@ Page Language="C#" EnableEventValidation="false" EnableViewStateMac="false" ...


Pronto, no meu caso resolveu, e se tiveres sorte também poderá resolver.

Wednesday, February 4, 2009

Compilando a última versão do WINE no Ubuntu

Para quem não sabe, o WINE permite rodar aplicações Windows em Linux/BSDs sem precisar de uma cópia do Windows. Basicamente, com ele é possível rodar a maioria dos programas desenvolvidos para Windows no Linux.

WINE quer dizer: Wine Is Not an Emulator! O WINE não é um emulador por que ele não emula a arquitetura de processadores do Windows, o Intel x86, ele simplismente consegue executar os binários do Windows na arquitetura em que esta rodando, como uma ponte entre os binários do Windows e o sistema nativa em que ele esta rodando (Linux/BSDs) independente da arquitetura do processador.

O Ubuntu tem o WINE disponível no repositório oficial, mas nunca é a versão mais resente, e como estão sempre melhorando para rodar melhor os programas Windows, convém mante-lo atualizado.

O WINE pode consumir bastante recursos da máquina, dependendo das aplicações que ele vai rodar (jogos por exemplo).

Por estas e outras o melhor é estar sempre com a versão mais recente e compilado para ter melhor desempenho.

Antes de mais, instalar as dependências do WINE:


$ sudo apt-get build-dep wine


Mas estas dependências não são completas, por isso veja em:

http://wiki.winehq.org/Recommended_Packages

E baixe e execute o arquivo de script de dependências correspondente a sua versão do Ubuntu, no meu caso:


$ wget http://winezeug.googlecode.com/svn/trunk/install-wine-deps.sh
$ chmod +x install-wine-deps.sh
$ sudo ./install-wine-deps.sh


Fazer o download da última versão do arquivo de source (.tar.bz2) do WINE em:

http://www.winehq.org/

Extrair o arquivo baixado. Através da console entrar dentro da pasta de sources do WINE e fazer:


$ ./configure


Se no final do "./configure" obtiver o seguinte warning:

configure: WARNING: No OpenGL library found on this system.
OpenGL and Direct3D won't be supported.


Então os links simbólicos da libGL não devem estar corretas, analise com:


$ ls /usr/lib/libGL* -o


É preciso que o link simbólico /usr/lib/libGL.so -> /usr/lib/libGL.so.XXX.XX esteja a apontar para a versão mais recente, onde "XXX.XX" é a identificação da versão mais alta, ou seja a mais recente, da libGL. Caso exista o link simbólico remova-o:


$ sudo rm /usr/lib/libGL.so


E agora crie o link simbólico para a versão mais recente que tiver:


$ sudo ln -s /usr/lib/libGL.so.XXX.XX /usr/lib/libGL.so


Tem que ser feito o ./configure outra vez, e agora sem o warning:


$ ./configure


Dependências e configurações feitas com sucesso, agora só falta compilar e instalar:


$ make depend && make
$ sudo make install


Pronto! Será criado menus para o WINE no menu de programas, e através da console é só executar:


$ wine ARQUIVO_EXECUTAVEL_DO_WINDOWS.exe


Para ver a lista dos programas suportados e a nível da qualidade de execução:

http://appdb.winehq.org/

Tuesday, February 3, 2009

Virtualização para servidores com VirtualBox

O que não falta agora é soluções de virtualização.

Mas a mais simples e com excelente performance na minha opinião é com o VirtualBox, dá para fazer tudo que é preciso com muita simplicidade e rapidez.

Para virtualização em desktop o VirtualBox já vem reinando a algum tempo.

E para servidor, muitos não apostam por que simplismente não sabem que é possível, mas dá! E não é preciso ter ambiente gráfico, usando o VRDP pode-se administrar a máquina remotamente. Mas convém ter o ambiente gráfico, tudo fica muito mais fácil, e hoje em dia não vejo por que não ter ambiente gráfico no servidor, pois o que não falta é ambientes gráficos levezinhos que nem afetam a performance do servidor.

Existe uma solução para máquinas virtuais usando OpenSolaris e VirtualBox, chamda xVM Server:
http://xvmserver.org/
http://www.sun.com/software/products/xvmserver/index.xml

Mas como já tenho o CentOS redondinho, agora é tarde.

Bem, então eu resolvi fazer de tudo para ter o VirtualBox trabalhando no servidor com o Windows 2003 Server em máquina virtual dentro do VirtualBox no CentOS 5.

Melhor impossível, ficou perfeito, excelente performance, fácil administração, todos serviços funcionando lindamente.

Vamos ao que interessa. Basicamente CentOS 5 com o VirtualBox instalado, com a máquina virtual para o Windows Server 2003 instalada e configurada, isto é moleza e o que não falta é tutoriais pela net ensinando como fazer isto com screenshots e tudo, e o VirtualBox é muito intuitivo. Por isso este não é o âmbito aqui.

Agora a parte mais complicada, que tive que pesquisar bastante, para fazer com que o CentOS comunicasse com o Windows Server. O que me ajudou mais a desvendar isto foi este script:

http://www.savvyadmin.com/virtualbox-host-interface-networking-with-nat/

Mas como nem tudo é perfeito, este script não serve no CentOS, é preciso algumas alterações.

Então em primeiro lugar, configurar o IP da máquina virtual, ir no Windows 2003 Server e configurar o TCP/IP assim:

IP address: 192.168.20.201
Subnet mask: 255.255.255.0
Default gateway: 192.168.20.1



Feito isto, ir no CentOS e criar uma interface de rede virtual:


# /usr/bin/VBoxTunctl -u root


Depois disto, pode verificar com o "/sbin/ifconfig -a" se aparece o tap0. Pronto ai esta a nossa interface de rede virtual.

É preciso configurar no VirtualBox para usar a nova interface de rede virtual, a tap0. Ir nos "Settings" da máquina virtual, em "Network", no "Attached to", mudar para "Host Interface", e selecionar a tap0. Para ir nos "Settings" tem que desligar a máquina virtual.

Settings da Máquina Virtual > Network > Attached to > Host Interface



Agora é preciso configurar a interface de rede virtual:


# /sbin/ip link set tap0 up
# /sbin/ip addr add 192.168.20.1/32 dev tap0
# /sbin/route add -host 192.168.20.201 dev tap0


Deverá conseguir "pingar" a máquina virtual:


# ping -c 1 192.168.20.201


Se for preciso rodar ASPX no servidor, ai esta a solução, só configuar no nginx para fazer proxy reverso do IIS no IP 192.168.20.201, e já vai funcionar perfeitamente.

A máquina virtual até aqui não tem acesso a internet. Para resolver isto é preciso fazer isto:


# /sbin/sysctl net.ipv4.ip_forward=1
# /sbin/iptables -t nat -A POSTROUTING --out-interface eth0 -j MASQUERADE
# /sbin/iptables -A FORWARD --in-interface tap0 -j ACCEPT


E também configurar os DNSs, primário e secundário, da máquina virtual, com os mesmos dados DNSs do CentOS, para ver os DNSs do CentOS:


# cat /etc/resolv.conf


Agora deverá ter a internet funcionando no Windows.

Podemos iniciar a máquina virtual pela linha de comando, só que ficamos sem acesso ao ambiente gráfico do VirtualBox. Para então ter acesso a máquina virtual convém configurar o VRDP no VirtualBox para acessar a máquina virtual remotamente:

Settings da Máquina Virtual > Remote Display > Enable VRDP Server

Settings da Máquina Virtual > Remote Display > Port = 3089



É importante mudar o número da porta, por que a porta do VRDP é a mesma do Terminal Services, da para trocar o número da porta do Terminal Services no regedit, mas é mais simples ai no VRDP, e assim já se evita um conflito.

Só que assim o VirtualBox vai deixar entrar qualquer um pelo VRDP sem autenticação, então convém bloquear a porta do VRDP para que ninguem fora do CentOS consiga controlar a máquina virtual:


# /sbin/iptables -A INPUT -p tcp -i eth0 --dport 3089 -j REJECT --reject-with tcp-reset

# /sbin/iptables -A INPUT -p tcp -i eth1 --dport 3089 -j REJECT --reject-with tcp-reset

# /sbin/iptables -A INPUT -p udp -i eth0 --dport 3089 -j REJECT

# /sbin/iptables -A INPUT -p udp -i eth1 --dport 3089 -j REJECT


Assim a porta do VRDP fica protegida para que ninguem que venha das interfaces de rede externas consiga conectar.

Para conectar via VRDP é só usar o tsclient:


# tsclient


No tsclient em computer colocar:

localhost:3089

E em protocol:

RDPv5

Clicar em "Connect", e pronto! Já conseguimos controlar a máquina virtual remotamente quando estivermos executando ela em background, isto será muito útil.

No Windows 2003 Server podemos ter o Terminal Services, e para acessar o terminal services através da internet ou rede temos que fazer uns ajustes, pois a porta do Terminal Services é a mesma do VRDP, então temos que mudar uma ou outra porta, como já mudamos a porta padrão do VRDP para 3089, então o Terminal Services vai funcionar bem na porta 3389.

Então para por o Terminal Services a funcionar é preciso ativar, no Windows Server:

Control Panel > System > Remote > Enable Remote Desktop on this computer



E agora é fazer NAT para a porta do Terminal Services:


# /sbin/iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 3389 -j DNAT --to 192.168.20.201:3389

# /sbin/iptables -t nat -A PREROUTING -p tcp -i eth1 --dport 3389 -j DNAT --to 192.168.20.201:3389


E assim fica o Terminal Services disponível, e o mesmo pode ser feito para outros serviços do Windows que precisam estar disponíveis externamente, como MSSQLServer.

Há outros exemplos desta configuração usando bridges, mas acho que assim fica muito mais simples.

Para iniciar a máquina virtual pela linha de comando é assim:


/usr/bin/VBoxVRDP -startvm NOME_DA_MAQUINA_VIRTUAL_NO_VIRTUALBOX


Para quando o servidor iniciar, iniciar também a máquina virtual e carregar toda configuração, coloquei os seguintes comandos no /etc/rc.local:


/usr/bin/VBoxTunctl -u root
/sbin/sysctl net.ipv4.ip_forward=1
/sbin/ip link set tap0 up
/sbin/ip addr add 192.168.20.1/32 dev tap0
/sbin/route add -host 192.168.20.201 dev tap0
/sbin/sysctl net.ipv4.ip_forward=1
/sbin/iptables -t nat -A POSTROUTING --out-interface eth0 -j MASQUERADE
/sbin/iptables -A FORWARD --in-interface tap0 -j ACCEPT
/sbin/iptables -A INPUT -p tcp -i eth0 --dport 3089 -j REJECT --reject-with tcp-reset
/sbin/iptables -A INPUT -p tcp -i eth1 --dport 3089 -j REJECT --reject-with tcp-reset
/sbin/iptables -A INPUT -p udp -i eth0 --dport 3089 -j REJECT
/sbin/iptables -A INPUT -p udp -i eth1 --dport 3089 -j REJECT
/sbin/iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 3389 -j DNAT --to 192.168.20.201:3389
/usr/bin/nohup /usr/bin/VBoxVRDP -startvm winserver > /dev/null &


Tem muita gente que acha deselegante usar o rc.local, mas eu não acho deselegante, muito pelo contrário, afinal pra que que ele serve? :P

No meu caso, em um AMD Opteron Quad-Core com 4GB de RAM, o Windows 2003 Server em máquina virtual de 512MB com o VirtualBox demora 6 segundos para estar completamente inicializado.