Hostname diferente do registro DNS e Replicação no SQL Server

Faz tempo que não escrevo nada por aqui, e numa ajuda a alguns amigos, me deparei com um problema que merece um post.

Objetivo do Cenário: Replicar (replicação merge) alguns itens de uma base de dados SQL Server entre duas máquinas.

Restrições:

  • A máquina SQL01 está com IP real;
  • A máquina SQL02 está em uma rede interna, em um lugar físico desconhecido para mim (tipo,… não mudaria em nada eu saber disso também….);
  • A versão do SGBD na SQL01 é 2012 Enterprise;
  • A versão do SGBD na SQL02 é 2008 Express;
  • Existe a possibilidade dessa replicação ser extendida para mais subscribers SQL Server 2005 Express;
  • Não há domínio Active Directory;

A replicação em si é bastante trivial (veja isso aqui, e um vídeo aqui). Existem vários tutoriais e vídeos explicando como implementar em cenários simples. Porém, com as restrições dadas, na hora de tentar criar a publicação, a tela abaixo vai surgir:

image

Ela nos informa que não foi possível conectar ao servidor XXX.com.br porquê o nome do servidor no SQL Server não é o mesmo que o FQDN, ou o nome da máquina inferido pelo registro de nomes (DNS) usado na conexão do Management Studio.

Para ver o nome do servidor, você pode verificar o valor da variável @@SERVERNAME, ou executar a consulta:

SELECT * FROM sys.servers;

Sendo assim, ganhei mais uma restrição (como se tivesse poucas):

  • O nome do meu registro no DNS precisa ser igual ao nome dado ao servidor.
    Não há tempo hábil para que o provedor de serviço possa criar um domínio de DNS e mais um registro específico no DNS para a máquina SQL01. Criar DNSs locais demandariam compra de novo IP fixo, e não parecem boas soluções.
    Uma alternativa para resolver o impasse seria mudar o nome do servidor. Isso pode ser feito manipulando o nome do servidor pelas procedures sp_addserver, sp_dropserver (depreciadas), sp_addlinkedserver e sp_droplinkedserver. Mas estas são operações que demandam muita configuração, e são bastante sensíveis, como pode ser visto aqui.
    Depois de uma pesquisa sobre o assunto encontrei um post que comenta sobre esse problema, e comenta uma solução: Criar um alias para a conexão no computador que está conectando para configurar a replicação.
    Para criar o alias, na sua máquina, onde você executa o Management Studio, abra o Configuration Manager do SQL Server. Expanda o item SQL Native Client Configuration, e clique com o botão direito em Aliases. Escolha a opção New Alias…. Teremos a caixa abaixo.

 

image

Nela, o Nome do Alias (Alias Name) vai ser o hostname local do servidor que você deseja se conectar. A porta é a 1433 (a replicação usa ela, conforme visto aqui). O servidor (Server) é o IP/FQDN do servidor SQL01.

Agora, na hora de executar o Management Studio, não use mais o FQDN do SQL01, mas sim o Nome do Alias criado no Configuration Manager, e tudo irá bem.

Deamon ipadcharge

Como já tinha comentado aqui em um post passado, para carregar um iPad no fedora era necessário um pouco de trabalho, envolvendo verificar algumas informações das portas usb e depois fazer uma chamada ao aplicativo ipad_charger.

Isso me incomodava, pois uso muito linux. Dessa maneira, começei a fazer o deamon para que ele ficasse ”plug’n’play” com qualquer dispositivo Apple. Com isso em mente criei o serviço ipadcharged que pode ser baixado em https://github.com/fchicout/ipadcharged.

Ele precisa ser configurado como um serviço em seu fedora, e esse procedimento deve ser realizado só uma vez. Para instalar em sua máquina, basta realizar os seguintes procedimentos (como root, ou sudoer):

wget https://raw.github.com/fchicout/ipadcharged/master/ipadcharged –O /etc/init.d/
cd /etc/init.d; chkconfig –add ipadcharged; chkconfig –levels 2345 ipadcarged on;

Quando isso é feito o serviço é instalado ao SO. Caso o pacote ipad_charger já esteja instalado, você pode mandar o comando abaixo para que ele começe a carregar os seus iDevices:

systemctl start ipadcharger.service

Caso não tenha o pacote instalado, execute (como root ou sudoer novamente):

/etc/init.d/ipadcharger install-pkg

e a instalação será realizada.

wget / axel no Windows

wget / axel no Windows

Hoje estava precisando fazer um download de um arquivo de 95MB numa rede ruim. Por conta disso lembrei de wget, ou de axel que funcionam muito bem em Linux como gerenciadores de download.

Já conhecia um projeto chamado BITS que é o módulo do Windows Update para download das atualizações. O que não sabia, era que podia usar tão fácil o BITS para realizar um download qualquer. Basta usar o seguinte:

Start-BITSTransfer -Source url -Destination local_path

Datas no SQL Server

Se quiser recuperar o dia da semana de uma data qualquer usando o SQL Server, é normal usar a funcão DATEPART, como se segue:

SELECT DATEPART(dw, ‘2012-07-28 18:33:48.197′)

E neste caso, a consulta de retorno será 7, que representa o sábado.

Existe também uma função DATENAME que é usada da mesma maneira que DATEPART, e que retorna o nome de uma data ou de um mês.

SELECT DATENAME(dw, ‘2012-07-28 18:33:48.197′)

Dessa maneira, no meu SQL Server em inglês, vai retornar Saturday. Talvez isso não seja exatamente algo útil no seu projeto, e voçê queira em outra língua. Faça então a configuração da linguagem do SQL Server. Use a seguinte instrução:

SET LANGUAGE ‘Brazilian’

e então o DATENAME anterior retornará Sábado.

Para descobrir quais línguas o SQL Server dá suporte, faça a seguinte consulta:

SELECT * FROM sys.syslanguages.

 

Referências:

Carregando o iPad no Fedora

20 junho, 2012 1 comentário

Vai ter gente lendo isso e achando maluquice, mas hoje sou um usuário 70% Linux e 30% Windows.

Ganhei um iPad no meu aniversário e comecei a enfrentar alguns problemas. O primeiro deles é que o iPad não carrega via USB quando ligado em um PC. Pesquisando com os amigos já usuários de Apple, informaram-me sobre o problema da voltagem necessária para carregamento do iPad, que a Apple tornou mais alta. Isso só acontecerá nos MacBooks recentes, mas não acontece por padrão nos PC’s. Alguns links sobre o assunto [em inglês]:

http://support.apple.com/kb/HT4060

http://www.pcworld.com/article/217116/why_doesnt_an_ipad_charge_when_connected_to_a_computer.html

http://www.iphonehacks.com/2010/04/ipad-not-charging.html

Para resolver em windows foi moleza. Alguns blogs apontam para baixar e instalar o programa da ASUS no link http://event.asus.com/mb/2010/ai_charger/ Isso resolveu perfeitamente nos meus 30% de uso Windows. Mas o problema maior estaria por vir. Os 70% de uso linux.

Sou hoje um usuário de fedora, e não foi tão tranquilo encontrar essa solução. Mas encontrei uma referência perdida (http://pkgs.org/fedora-17/rpm-sphere-x86_64/ipad_charge-1.1-3.1.x86_64.rpm.html) ao pacote ipad_charge.x86_64.rpm. Além disso, encontrei o seguinte bug issue na red hat: https://bugzilla.redhat.com/show_bug.cgi?id=741249.

Bem no primeiro link, encontrei o repositório que possui o rpm. Só seguir os passos:

  • Criar um arquivo sphere.repo na pasta /etc/yum.repos.d
  • Nele incluir o seguinte conteúdo:
[rpm-sphere]
name=RPM Sphere
baseurl=http://download.opensuse.org/repositories/home:/zhonghuaren/Fedora_17/
gpgkey=http://download.opensuse.org/repositories/home:/zhonghuaren/Fedora_17/repodata/repomd.xml.key
enabled=1
gpgcheck=1
  • Instalar o pacote com o comando:
 yum install ipad_charge

Mas isso pode não ser suficiente. No meu caso, o fedora não consegui passar a informação para o executável do charger de qual porta usb tinha de ser carregada. Investigando o executável, ele mostra que podem ser definidas duas variáveis de ambiente, a BUSNUM e a DEVNUM, que indicam o caminho para o Fedora da porta USB na qual ele deve trabalhar. Para descobrir qual porta o seu iPad está conectado, use o comando lsusb, que deve mostrar algo semelhante ao que está abaixo:

Bus 001 Device 007: ID 05ac:12a6 Apple, Inc.
Bus 001 Device 005: ID 0c45:62c0 Microdia Sonix USB 2.0 Camera
Bus 001 Device 003: ID 0cf2:6230 ENE Technology, Inc.
Bus 001 Device 004: ID 04e8:1f06 Samsung Electronics Co., Ltd
Bus 002 Device 003: ID 0bda:8189 Realtek Semiconductor Corp. RTL8187B Wireless 802.11g 54Mbps Network Adapter
Bus 007 Device 003: ID 045e:0745 Microsoft Corp. Nano Transceiver v1.0 for Bluetooth
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Com essa saída, fica claro que BUSNUM=001 e DEVNUM=007 no meu caso, e dessa maneira, o executável do charger deve ser chamado via terminal como se segue:

$ BUSNUM=001 DEVNUM=007 /usr/bin/ipad_charge

E a partir daí você verá seu iPad dizendo que está carregando.

Inícios de Estudos – LPI

Uma boa galera do trabalho está com interesse de tirar certificação Linux, e vamos começar com LPI-I. Parece-me um bom entry-point para outras certificações em Linux.

Dessa maneira, comecei a procurar alguns materiais, pois em breve terei de apresentar sobre o primeiro tópico da prova, Arquitetura do Sistema. E a idéia é antes buscar materiais, estudar e compartilhar. Inclusive, compatilharemos aqui neste blog, que até então foi o repositório de idéias úteis de uma pessoa só (em breve faço um post falando dos que irão contribuir aqui).

Ah! Falando em materiais, já encontrei alguns que servirão de base para o assunto que vou apresentar. Se encontrar mais coisas, vou atualizando o post.

 

http://www.lpibrasil.com.br/auto-estudo-lpi/topico-101-arquitetura-sistema-1011-configuracao-hardware.html

Testes com Selenium

Dia desses deparei-me com uma configuração de servidor que poderia acabar impactando em algumas funcionalidades de um site. Começei então a procurar alguma maneira de testar uma aplicação Web simulando o comportamento do usuário em um browser, e encontrei o Selenium. É um projeto bastante interessante, multiplataforma, com o intuito de automatizar navegadores. Como hoje estou trabalhando quase sempre no contexto da administração de sistemas, Python é a melhor alternativa para trabalhar com este tipo de teste.

Instalação

Estando em um Fedora 16, a instalação fica bastante simplificada, porém não tem as chamadas padrão (conforme documentação do selenium) para inicialização do server. Primeiro passo é instalar o selenium. Pra isso, num terminal, entre com:

sudo pip-python install selenium

Depois é interessante instalar o pacote selenose, para construir os testes no lado cliente. O nose-notify vale para integrar os resultados e com o sistema de notificações do Gnome.

sudo pip-python install selenose, nose-notify

Desenvolvimento dos Testes

Agora, basta começar a construir os testes puramente em python. Para mostrar um “Hello World” de exemplo, segue (salve com o nome webTest.py):

#!/usr/bin/python

import nose
import unittest

from selenium import webdriver

class TestCase(unittest.TestCase):
  def test(self):
    driver = webdriver.Remote(desired_capabilities=webdriver.DesiredCapabilities.FIREFOX)
    try:
      driver.get('http://www.google.com')
      print "Tests Run"
    finally:
      driver.quit()

if __name__ == '__main__':
  nose.main()

Execução

Para executar os testes, em um terminal, execute selenium-server e depois, execute o seu arquivo de teste com o nose.

selenium-server
nosetests webTest.py

O resultado deve ser como se segue no terminal e o seu Firefox deve abrir e chamar o site do google.

[fchicout@fchicout-pc ~]$ nosetests webTest.py
.
----------------------------------------------------------------------
Ran 1 test in 9.666s

OK
Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

Junte-se a 292 outros seguidores

%d blogueiros gostam disto: