sexta-feira, 16 de julho de 2010

Como colocar autenticação básica no console web do Fuse Message Broker v5.3

Até a versão 5.4 o Fuse Message Broker disponibiliza livre acesso a ferramenta de administração. Este é o padrão de instalação, porém, quando disponibilizamos este servidor para acesso de outros recursos, muitas vezes não queremos que qualquer pessoa efetue modificações sem nossa permissão. Uma forma simples de resolver isso (quando os requisitos de segurança não forem muito rígidos, por exemplo, na criação de um servidor interno para desenvolvimento) é habilitar a autenticação básica para entrar em qualquer URL pertinente a área de administração.

O arquivo que iremos alterar está localizado na pasta conf do fuse message broker, e para encontrá-lo devemos executar os seguintes comandos (tomamos como padrão o exemplo de caminhos utilizados no artigo de que ensina a instalar o Fuse Message Broker publicado por mim neste mesmo blog):

cd /opt/fuse-message-broker-5.3.1/conf

Para executar este procedimento, primeiramente devemos alterar o arquivo jetty.xml adicionando as seguintes configurações:

<!-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to You under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.--><!-- An embedded servlet engine for serving up the Admin consoles, REST and Ajax APIs and some demos Include this file in your configuration to enable ActiveMQ web components e.g. <import resource="jetty.xml"/>-->

<beans
xmlns="http://www.springframework.org/schema/beans"
xmlns:jetty="http://mortbay.com/schemas/jetty/1.0"
xmlns:util="http://www.springframework.org/schema/util"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
<bean id="userRealm" class="org.mortbay.jetty.security.HashUserRealm">
<property name="name" value="ActiveMQRealm"/>
<property name="config" value="${activemq.base}/conf/jetty-realm.properties"/>
</bean>
<bean id="securityConstraint" class="org.mortbay.jetty.security.Constraint">
<property name="name">
<util:constant static-field="org.mortbay.jetty.security.Constraint.__BASIC_AUTH"/>
</property>
<property name="roles">
<list><value>admin</value></list>
</property>
<property name="authenticate" value="true"/>
</bean>
<bean id="securityConstraintMapping" class="org.mortbay.jetty.security.ConstraintMapping">
<property name="constraint" ref="securityConstraint"/>
<property name="pathSpec" value="/*"/>
</bean>
<bean id="securityHandler" class="org.mortbay.jetty.security.SecurityHandler">
<property name="userRealm" ref="userRealm"/>
<property name="constraintMappings">
<list>
<ref bean="securityConstraintMapping" />
</list>
</property>
</bean>
<bean id="Server" class="org.mortbay.jetty.Server" init-method="start" destroy-method="stop">
<property name="connectors">
<list>
<bean id="Connector" class="org.mortbay.jetty.nio.SelectChannelConnector">
<property name="port" value="8161"/>
</bean>
</list>
</property>
<property name="handler">
<bean id="handlers" class="org.mortbay.jetty.handler.HandlerCollection">
<property name="handlers">
<list>
<ref bean="securityHandler" />
<bean id="contexts" class="org.mortbay.jetty.handler.ContextHandlerCollection">
...


Este arquivo faz referência a um arquivo de properties que deve conter o nível de privilégio, usuário e senha este arquivo deve ser criado na mesma pasta (conf) e o nome deve ser jetty-realm.properties. Para executar este passo digite o seguinte comando:

sudo pico jetty-realm.properties

E insira o seguinte conteúdo:

## ---------------------------------------------------------------------------
## Licensed to the Apache Software Foundation (ASF) under one or more
## contributor license agreements. See the NOTICE file distributed with
## this work for additional information regarding copyright ownership.
## The ASF licenses this file to You under the Apache License, Version 2.0
## (the "License"); you may not use this file except in compliance with
## the License. You may obtain a copy of the License at
##
## http://www.apache.org/licenses/LICENSE-2.0
##
## Unless required by applicable law or agreed to in writing, software
## distributed under the License is distributed on an "AS IS" BASIS,
## WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
## See the License for the specific language governing permissions and
## limitations under the License.
## ---------------------------------------------------------------------------
# Defines users that can access the web (console, demo, etc.)
# username: password [,rolename ...]
admin: admin, admin


Então devemos alterar o owner do arquivo, para o mesmo usuário que é utilizado para inicializar o Fuse Message Broker:

sudo chown fuse-message-broker jetty-realm.properties

E então basta executar o comando para inicializar o Fuse Message Broker:

sudo service fuse-message-broker start

e tentar acessar a url de administração:

http://localhost:8161/admin

Se o procedimento for executado corretamente, uma janela pedindo usuário e senha será exibida antes que você possa navegar e utilizar o console.

Referências:
http://www.nighttale.net/activemq/securing-activemq-531-console.html
http://github.com/dejanb/activemq-util/blob/master/config/5.3.1/jetty/jetty.xml

segunda-feira, 12 de julho de 2010

Como criar novos tópicos e novas filas na inicialização do Fuse Message Broker v5.3

Previamente abordamos a instalação do Fuse Message Broker e como configurá-lo para inicialização através de serviço do Ubuntu. Neste novo artigo abordaremos como criar um novo destino de mensagens para o nosso message broker previamente instalado. Existem duas possibilidades para gerar um novo destino de mensagens no Fuse Message Broker. Uma delas é utilizar a criação em tempo de execução, e esta pode ser executada através de:

- chamada a createQueue() através de uma sessão JMS.
- criar uma instância de ActiveMQTopic ou ActiveMQQueue e registrar como um recurso JNDI para o seu servidor.


Ou podemos determinar que destinos serão criados ao inicializarmos a ferramenta (se configurado conforme artigo anterior, através do comando sudo service fuse-message-broker start). Para configurar uma fila ou um tópico seguindo o segundo exemplo devemos alterar a configuração do arquivo activemq.xml. Este arquivo se encontra na pasta conf dentro do caminho de instalação escolhido para a ferramenta. Seguiremos os caminhos especificados durante a nossa instalação demonstrada no artigo anterior:

cd /opt/fuse-message-broker-5.3.1/conf
sudo pico activemq.xml


E devemos inserir o seguinte conteúdo:

<beans
xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://activemq.apache.org/schema/core http://activemq.apache.org/schema/core/activemq-core.xsd
http://camel.apache.org/schema/spring http://camel.apache.org/schema/spring/camel-spring.xsd">
...
<broker xmlns="http://activemq.apache.org/schema/core">
...
<destinations>
<queue physicalName="FOO.BAR" />
<topic physicalName="SOME.TOPIC" />
</destinations>
...
</broker>
</beans>


com esta configuração dizemos que ao inicializar o message broker, criaremos um tópico denominado SOME.TOPIC e uma fila denominada FOO.BAR.

Referência
http://activemq.apache.org/how-do-i-create-new-destinations.html
http://activemq.apache.org/configure-startup-destinations.html

quarta-feira, 30 de junho de 2010

Instalando o Fuse Message Broker v5.3 no Ubuntu 10.04 LTS

Para instalar o fuse message broker v5.3 no Ubuntu 10.04 LTS inicialmente devemos efetuar o download do arquivo de instalação. Para isso executamos os seguintes comandos:

cd ~
mkdir installs
cd installs
mkdir fuse-message-broker
cd fuse-message-broker
wget http://repo.fusesource.com/maven2/com/iona/fuse/fuse-message-broker/5.3.1-02-00/fuse-message-broker-5.3.1-02-00-unix.bin


Após o término do download, vamos executar o instalador em modo console:

chmod +x fuse-message-broker-5.3-unix.bin
sudo sh fuse-message-broker-5.3-unix.bin -i console


Devemos executar o instalador com o comando sudo pois instalaremos o aplicativo na pasta /opt e é necessário ter permissão de escrita para instalar nesta pasta. O termo de licença será apresentado e devemos pressionar até que este seja finalizado. Quando este terminar, devemos aceitar os termos e então será oferecido o seguinte caminho de instalação /opt/progress/fuse-message-broker-5.3.1-02-00 (ou algo semelhante dependendo da sua versão). Eu gosto de mudar esta estrutura para facilitar meus scripts para /opt/fuse-message-broker-5.3.1.

O script começará a instalação e uma barra de progresso será exibida. Ao finalizar o instalador oferece a opção de salvar a configuração da instalação caso seja necessário executar uma instalação idêntica em outros servidores ou caso queira efetuar a mesma instalação novamente posteriormente. Digite Y caso queira salvar ou N caso não seja necessário.

Uma mensagem de sucesso será exibida contendo a pasta em que o software foi instalado. Pressione para retornar ao prompt. É válido ressaltar que a qualquer momento durante a instalação podemos inserir o comando de desistência:

quit

vamos colocar o usuário fuse-message-broker como owner da nossa pasta:

sudo chown fuse-message-broker /opt/fuse-message-broker-5.3.1 -R

Para configurar o software gerenciador de filas, devemos executar o seguinte comando:

cd /opt/fuse-message-broker-5.3.1/conf
sudo pico activemq.xml


Este arquivo contém algumas configurações para o servidor de filas. Todas as linhas são comentadas e aconselho a ler cada um dos comentários com paciência e pesquisar á respeito quando tiver alguma dúvida. O primeiro item que mudo na minha configuração é a seguinte:

<broker ... brokerName="localhost">

para:

<broker ... brokerName="myname-broker">

Vamos adicionar um usuário para executar inicializar o Fuse Message Broker com permissões limitadas e criar um diretório de logs para jogar a saída da inicialização do nosso broker:

sudo adduser --system fuse-message-broker
sudo -u fuse-message-broker mkdir /home/fuse-message-broker/logs


E vamos criar um script para inicialização da nossa instância como um serviço do ubuntu:

cd /etc/init.d/
sudo pico fuse-message-broker


E inserir o seguinte conteúdo dentro do arquivo:

#! /bin/sh

FUSEMESSAGEBROKER_HOME=/opt/fuse-message-broker-5.3.1

start(){
echo "Starting Fuse Message Broker 5.3.1
sudo -u fuse-message-broker sh ${FUSEMESSAGEBROKER_HOME}/bin/activemq > /home/fuse-message-broker/logs/out.log
}
stop(){
echo "Stopping Fuse Message Broker 5.3.1"
sudo -u fuse-message-broker sh ${FUSEMESSAGEBROKER_HOME}/bin/activemq-admin stop >> /home/fuse-message-broker/logs/out.log
sleep 60
}
restart(){
stop
start
}

case "$1" in
start)
start
;;
stop)
stop
;;
restart)
restart
;;
*)
echo "Usage: fuse-message-broker {start|stop|restart}"
exit 1
esac
exit 0


Para inicializar o nosso broker utilizamos o seguinte comando:

sudo service fuse-message-broker start

Para parar o mesmo utilizamos:

sudo service fuse-message-broker stop

Para acompanhar a saída da nossa instância (que não está sendo redirecionada para a saída padrão) devemos executar o seguinte comando:

tail -f /home/fuse-message-broker/logs/out.log

Futuramente configuraremos nosso fuse message broker para habilitar outros protocolos e otimizar seu desempenho, mas por enquanto tempo o broker rodando com as configurações padrões.

Referências:
http://fusesource.com/docs/broker/5.3/getting_started/index.html

Instalando JBoss 5.1 GA no Ubuntu Server 10.04

Neste artigo presumo que você já tenha instalado a JDK 6 e tenha o servidor ubuntu executando corretamente. Primeiramente é necessário baixar o instalador do JBoss 5.1 GA do site da jboss.org. Para efetuar o download, primeiramente criaremos uma pasta para armazenar o arquivo.

cd ~
mkdir installs
cd installs
mkdir jboss
cd jboss
wget http://sourceforge.net/projects/jboss/files/JBoss/JBoss-5.1.0.GA/jboss-5.1.0.GA.zip.MD5/download


Quando baixamos o arquivo de instalação do JBoss, este vêm em formato .zip e será necessário descompactá-lo, para efetuarmos este procedimento precisamos da ferramenta unzip. Para instalar o unzip utilize o seguinte comando (ps. quando instalo o unzip já aproveito e instalo a ferramenta zip, para compactar arquivos):

sudo apt-get install unzip zip

Instalaremos o servidor de aplicação dentro da pasta /opt executando os seguintes comandos:

unzip jboss-5.1.0.GA.zip
sudo mv jboss-5.1.0.GA


Agora vamos criar um usuário para executar o servidor de aplicação:

sudo adduser --system jboss
sudo -u jboss mkdir /home/jboss/logs


E alterar o owner da nossa pasta jboss-5.1.0.GA para o usuário jboss (para que este tenha permissão de manipular os arquivos e executar os scripts existentes na pasta. A opção -R adiciona a permissão de forma recursiva para as subpastas e arquivos):

sudo chown jboss /opt/jboss-5.1.0.GA -R

E para facilitar nossa vida, vamos criar um script que permite inicializar o jboss como serviço no linux:

cd /etc/init.d/
sudo pico jboss


E insira o seguinte conteúdo no script em criação:

#! /bin/sh

JBOSS_HOME=/opt/jboss-5.1.0.GA

start(){
echo "Starting jboss.."
sudo -u jboss ${JBOSS_HOME}/bin/run.sh -b 0.0.0.0 > /home/jboss/logs/out.log &
}

stop(){
echo "Stopping jboss.."
sudo -u jboss ${JBOSS_HOME}/bin/shutdown.sh -S >> /home/jboss/logs/out.log &

#give time to shutdown jboss services.
sleep 60

#kill all java services started by user jboss
su -l jboss -c 'killall java'
}

restart(){
stop
start
}

case "$1" in
start)
start
;;
stop)
stop
;;
restart)
restart
;;
*)
echo "Usage: jboss {start|stop|restart}"
exit 1
esac

exit 0


Confirme que o script possui permissão de execução:
ls -l

e caso não tenha execute o seguinte comando:

sudo chmod +x jboss

E então use o seguinte comando para inicializar o jboss:

sudo service jboss start

Para parar o serviço do jboss basta executar:

sudo service jboss stop

E caso decida inicializar o serviço do jboss ao inicializar o sistema opercional, basta executar o seguinte comando:

sudo update-rc.d /etc/init.d/jboss defaults

Caso queira acompanhar a inicialização, basta seguir os seguintes passos:

sudo service jboss start

Mudar de terminal

tail -f /home/jobss/out.log

Referência:

http://dhydrated.wordpress.com/2009/09/25/setup-jboss5-in-ubuntu/

terça-feira, 8 de junho de 2010

Hierarquia de Sistema de Arquivos para instalação e distribuição de Aplicativos Linux

Ontem estava discutindo com um amigo sobre qual seria a melhor estrutura de instalação para um software no sistema operacional linux, e então resolvi fazer uma pesquisa simples á respeito do assunto. Simplificando a explicação, vamos utilizar como exemplo um servidor de aplicações (i.e. Weblogic). Em um cenário ideal, colocaríamos o software em /usr, os arquivos de configuração em /etc, as aplicações do servidor em /srv e por fim os logs em /var/log.

Esta seria a estrutura ideal porém muitos aplicativos não permitem tal divisão. Como exemplo disso temos o JBoss Application Server, que até a versão 5.1 não permitia que os arquivos de configuração fossem colocados em /etc. Neste caso, muitas vezes o problema pode ser resolvido colocando o seu software em /usr/local ou /opt. Este procedimento não é a melhor opção, mas ainda assim é uma prática válida.

Existe um site destinado a explicar a hierarquia de sistema de arquivos para linux (http://proton.pathname.com/fhs/) e este descreve as melhores práticas para instalação de softwares em estrutura linux para desenvolvedores e administradores de servidores.

Referências:
http://chiralsoftware.com/linux-system-administration/jboss-server-deployment.seam

quarta-feira, 19 de maio de 2010

Unified Process e Use Case Points: Transparência nos Prazos sem Esforços Adicionais

Atualmente presenciamos um grande crescimento da utilização do Unified Process (UP) como metodologia de desenvolvimento de software no mercado, porém, a maioria das empresas continuam utilizando Análise por Pontos de Função (Function Point Analisys ou FPA) para extrair métricas de software e gerar estimativas sem sequer estudar outras possibilidades existentes. Neste artigo introduziremos o método de Use Case Points (UCP), ressaltaremos seus pontos positivos, os pontos negativos, apresentaremos uma breve sugestão de como implantar o mesmo em empresas durante o processo de adoção do UP e concluiremos com um breve comentário sobre os temas abordados.

O UP determina que para obtermos o bom andamento de um projeto é necessário que os casos de uso sejam identificados, diagramados e descritos de forma correta pois estes definem as funcionalidades que devem ser entregues ao fim do projeto. Nada melhor que utilizar um documento que lista os requisitos funcionais para medir o tamanho do software a ser desenvolvido. O método UCP foi proposto em 1993 por Gustav Karner e têm como objetivo permitir que seja possível estimar o tamanho de um sistema durante a fase de levantamento de casos de uso, ou seja, aproveitar os diagramas de casos de uso criados por exigência da metodologia e o conhecimento dos analista que os desenvolveram em relação ao projeto para dimensionar o sistema a ser implementado.

Utilizando UCP para extração de métricas teremos um procedimento condizente com a metodologia que estamos implantando, aproveitaremos o conhecimento dos analistas de sistema que efetuaram o levantamento de requisitos e criaram os casos de uso, teremos apoio de documentos previamente aprovados pelo cliente (diagramas de casos de uso) para explicar os prazos e esforços apresentados para desenvolver uma determinada funcionalidade solicitada. Desta forma não dependeremos de protótipos de telas para realizar a mensuração na fase inicial do projeto, tendo em vista que o desenvolvimento de protótipos de tela não são obrigatórios para a utilização do UP e o desenvolvimento de casos de uso na disciplina de requisitos são.

Depois de apresentarmos alguns pontos positivos devemos apresentar também os pontos negativos, sendo que durante a sugestão de implantação perceberemos que nem todos são necessariamente problemas na adoção e podem ser facilmente contornados. O UCP é um método que não disponibiliza muita fonte para consultas, dificultando o aprendizado para os interessados e também o solucionamento de dúvidas devido a existirem poucos profissionais capacitados. Atualmente este método não possui nenhum órgão certificador, impossibilitando desta forma, comprovar o conhecimento através de provas ou algo semelhante. Existem poucos profissionais com conhecimento avançado na criação de casos de uso, o que conduz a diagramas com decomposição funcional ou até mesmo diagramas “CRUD” (Create, Read, Update, Delete), como são conhecidos no mercado, resultando na extração de métricas incorretas. O UCP exige que uma base prévia de conhecimento seja utilizada para refinar as estimativas geradas, e esta base, devido a mudança do procedimento, dificulta ou até mesmo inviabiliza o reaproveitamento de conhecimentos adquiridos em projetos anteriores.

Inicialmente os pontos negativos parecem ser muito fortes, porém, através de uma análise mais detalhada podemos ver que a maioria destes podem ser contornados ou até mesmo utilizados como pontos positivos. Utilizar o UCP inibe a criação de diagramas de casos de uso incorretos pois os erros impactariam diretamente na estimativa de esforços para desenvolver o projeto, forçando a revisão dos diagramas previamente citados. Os casos de uso são utilizados para eliminar compreensões ambíguas e, para o sucesso de um projeto baseado na metodologia UP é essencial que o time seja composto por profissionais capacitados em desenvolvê-los com eficiência e corretude. Todos estes fatores agregam pontos ao acerto do dimensionamento do projeto e também a criação de diagramas de caso de uso corretos.

Para explicar como solucionar o problema de criação de uma base de conhecimento com informações de projetos anteriores exigida pelo UCP, utilizaremos a sugestão de procedimento de implantação citado no início do artigo. Quando uma corporação define migrar para o UP, a estratégia mais coerente (na maioria dos casos) é preparar um time, selecionar as disciplinas a serem implantadas inicialmente e destinar um projeto pequeno e de baixo risco á utilização da metodologia. Ao fim deste , os profissionais com o conhecimento adquirido atuam como mentores em outros projetos, que passam a utilizar a nova metodologia e o conhecimento vai sendo difundido na empresa de forma transparente. Neste processo, podemos mesclar a adoção do UCP, realizando a extração de métricas através deste método, durante o projeto inicial baseado em UP. Ao fim do projeto populamos a base de conhecimento, que crescerá juntamente com a utilização do UP dentro da corporação. Este procedimento torna transparente o impacto da falta de experiências passadas com UCP e faz com que a evolução seja transparente aos envolvidos.

Devido a todos os fatores apresentados anteriormente, acredito que o UCP já está suficientemente maduro para ser aplicado em ambientes corporativos e a sua utilização reforça a importância dos casos de uso bem definidos em um projeto baseado em Unified Process. Sua utilização auxilia na identificação de erros em requisitos ou casos de uso, sendo esta mais uma oportunidade de identificar casos de uso mal desenvolvidos que poderiam conduzir o projeto ao fracasso. Devido a sua afinidade com a metodologia UP, o crescimento da sua utilização é inevitável, tornando desta forma o procedimento para estimativas e mensuração de sistemas mais natural, transparente e preciso.

terça-feira, 18 de maio de 2010

Configurando o Samba para integração Windows/Linux no Ubuntu 10.04 LTS Server

Este procedimento foi executado em uma máquina virtual configurada sobre o Windows 7. O software de virtualização utilizado foi o VMWare Workstation. O Samba é um componente que permite a integração entre o Windows e o Linux (mais em http://www.samba.org/). No final da instalação do Ubuntu 10.04 LTS Server são oferecidos diversos serviços adicionais que podem ser instalados (ex. LAMP, DNS, etc) e um destes é o Samba.

Caso não tenha selecionado a sua inclusão durante a instalação do sistema operacional, é possível instalar o pacote através do aptitude (Gerenciador de pacotes do Ubuntu). Para instalar o samba e os componentes necessários devemos executar o seguinte comando:

sudo apt-get install samba

Para configurar o serviço, primeiramente necessitamos pará-lo, logo, Ubuntu 10.04 utilizamos o comando:

sudo service smbd stop

Enquanto que nas versões anteriores utilizávamos o comando:
sudo /etc/init.d/samba stop

Agora que já instalamos os pacotes necessários, precisamos começar a configuração do Samba. A configuração é feita no arquivo smb.conf, porém, devido a possibilidade de cometer algum erro, primeiramente efetuaremos um backup do arquivo existente (default):

sudo mv /etc/samba/smb.conf /etc/samba/smb.conf.template

Então efetuaremos um comando touch para alterar a data de criação/modificação do arquivo que será alterado (o comando touch cria um arquivo caso este não exista ou altera a data de criação/modificação caso o mesmo já exista):

sudo touch /etc/samba/smb.conf

O passo anterior não é obrigatório porém modifica as propriedades do arquivo que iremos alterar e facilita a distinção do mesmo. Agora efetuaremos as alterações necessárias para que a integração funcione:

sudo pico /etc/samba/smb.conf

Abaixo está a configuração que deve ser inserida no arquivo smb.conf:

[global]
; Configurações gerais do servidor
netbios name = NOMEDAMAQUINALINUX
server string =
workgroup = WORKGROUPDOWINDOWS
announce version = 5.0
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE SO_RCVBUF=8192 SO_SNDBUF=8192

passdb backend = tdbsam
security = user
null passwords = true
username map = /etc/samba/smbusers
name resolve order = hosts wins bcast

; defina como yes caso sua máquina windows possua um IP fixo e no para máquinas
; com IP dinâmico.
wins support = yes

printing = CUPS
printcap name = CUPS

syslog = 1
syslog only = yes

; NOTE: Caso você necessite de acesso aos diretórios home do usuário descomente
; as linhas abaixo e configure de acordo com a sua necessidade
;[homes]
;valid users = %S
;create mode = 0600
;directory mode = 0755
;browseable = no
;read only = no
;veto files = /*.{*}/.*/mail/bin/

; NOTE: É necessário configurar caso você execute o samba em um controlador de
; domínio primário.
; Não cobrimos configuração de controlador de domínio primário aqui.
;[netlogon]
;path = /var/lib/samba/netlogon
;admin users = Administrator
;valid users = %U
;read only = no

; NOTE: É necessário configurar caso você execute o samba em um controlador de
; domínio primário.
; Não cobrimos configuração de controlador de domínio primário aqui.
;[Profiles]
;path = /var/lib/samba/profiles
;valid users = %U
;create mode = 0600
;directory mode = 0700
;writeable = yes
;browseable = no

; NOTE: Aqui configuramos um local para construir repositório de drivers de
; impressora para o windows. Não foi coberto aqui.
[print$]
path = /var/lib/samba/printers
browseable = yes
guest ok = yes
read only = yes
write list = root
create mask = 0664
directory mask = 0775

[printers]
path = /tmp
printable = yes
guest ok = yes
browseable = no

; Descomente as linhas abaixo caso precise compartilhar o CD/DVD-ROM
;[DVD-ROM Drive]
;path = /media/cdrom
;browseable = yes
;read only = yes
;guest ok = yes

[MyFiles]
path = /media/samba/
browseable = yes
read only = no
guest ok = no
create mask = 0644
directory mask = 0755
force user = NOMEDEUSUARIOWINDOWS
force group = NOMEDEUSUARIOWINDOWS


Nas configurações demonstrada acima existem alguns valores que devem ser substituídos para a sua necessidade. Os valores são:

NOMEDAMAQUINALINUX = Nome da máquina windows envolvida na configuração. Pode ser obtido clicando com o botão direito sobre o ícone "Meu Computador", selecionando "Propriedades" e verificando o "Nome da Máquina".
WORKGROUPDOWINDOWS = para encontrar o valor a ser inserido no lugar deste texto devemos seguir o mesmo procedimento mencionado acima, porém desta vez verificando o item "Grupo de Trabalho".
NOMEDEUSUARIOWINDOWS = Nome do usuário utilizado para entrar no windows. Pode ser verificado navegando em "Painel de Controle", "Contas de Usuários" e então "Modificar Sua Foto". Na parte superior da janela será exibido seu nome de usuário.

Após finalizarmos a criação do arquivo acima precisamos criar o diretório a ser compartilhado e alterar suas permissões:

sudo mkdir /media/samba
sudo chmod 0777 /media/samba

Agora devemos inicializar o serviço novamente utilizando o seguinte comando no Ubuntu 10.04 LTS Server:

sudo service smbd start

Ou o seguinte comando em versões anteriores:

sudo /etc/init.d/samba start

Nosso serviço está em execução, porém é necessário inserir e habilitar um usuário para autenticação do windows no nosso servidor linux. Esse procedimento é executado da seguinte forma:

sudo useradd -s /bin/true NOMEDEUSUARIOWINDOWS
sudo smbpasswd -L -a NOMEDEUSUARIOWINDOWS
sudo smbpasswd -L -e NOMEDEUSUARIOWINDOWS


Finalizamos a configuração do Samba no nosso servidor e para efetuar um teste retornamos ao Windows e clicamos em "Iniciar", Selecionamos "Programas", "Acessórios" e então "Executar" ou pressionamos o atalho "Win + r". Na caixa que será aberta digitaremos o seguinte comando caso a configuração de wins tenha sido definida como "yes" (Máquinas com IP fixo):

\\NOMEDAMAQUINALINUX\MyFiles

ou o seguinte comando caso wins tenha sido definida como "no" (Máquinas com IP dinâmico):

\\IPDAMAQUINALINUX\MyFiles

Para pegar o ip da máquina linux basta acessar o servidor e digitar o seguinte comando em um terminal:

ifconfig

Agora sua máquina Windows consegue acessar um diretório do servidor Linux e esperamos que isso facilite sua transferência de arquivos entre um servidor de desenvolvimento ou uma máquina virtual. Lembramos que não é seguro liberar compartilhamento de pastas em servidores e este procedimento deve ser executado com parsimônia. Caso queira aumentar um pouco a segurança do compartilhamento é possível definir as interfaces de rede através das quais o compartilhamento pode ser acessado inserindo a seguinte linha no smb.conf:

[global]
...
interfaces = lo, eth0 ; apenas acesso local ou através da interface eth0
; que normalmente é a interface para RJ45.
bind interfaces = true;

Finalizamos assim a configuração do Samba no Ubuntu 10.04 LTS Server e estamos prontos para acessar a pasta e transferir arquivos entre nossa máquina Windows e Linux.

Referência:
http://ubuntuforums.org/showthread.php?t=202605

Instalando o MySQL 5.1 no Ubuntu 10.04 LTS Server

Ontem instalei o MySQL no Ubuntu 10.04 LTS Server e o procedimento foi bem simples. O passo a passo explicado abaixo foi realizado utilizando uma máquina virtual (VMWare) e esta tinha acesso a internet através de NAT.

Minha instalação do ubuntu estava limpa, então tive que editar a lista de recursos para que o apt me oferecesse todos os pacotes necessários. Para isso executei o comando:

sudo pico /etc/atp/sources.list

removi os comentários de repositórios indisponíveis (para isto basta remover o caracter # da linha a ser descomentada). Fechei o arquivo (ctrl + x) e mandei que salvasse na saída (ctrl + s).

Após atualizar o arquivo sources.list, executei o comando para que o apt verificasse os novos repositórios e disponibilizasse os softwares para instalação:

sudo apt-get update

Neste ponto o sistema operacional estava pronto para a instalação do MySQL, o qual foi executado com o seguinte comando:

sudo apt-get install mysql-server-5.1 libmysqlclient16-dev

Quando terminamos a instalação da base de dados o serviço é automaticamente inicializado. Para verificar se este foi inicializado com sucesso podemos verificar se existe alguma porta ouvindo requisições para o mysql através do comando:

netstat -tap

Caso este não tenha sido inicializado podemos fazê-lo através do comando:

sudo service mysql start

Por questões de segurança o MySQL permite conexões apenas do localhost (default bind address). Para aceitarmos conexões de endereços externos devemos abrir o arquivo my.cnf através do comando:

sudo pico /etc/mysql/my.cnf

e comentar a linha:

bind-address = 127.0.0.1

Para comentar a linha basta adicionar um # no começo:

# bind-address = 127.0.0.1

Após todas essas alterações reiniciei o serviço utilizando o comando

sudo service mysql restart

Para reforçar um pouco a segurança do servidor de base de dados efetuei alguns procedimentos básicos. Primeiramente conectei no Mysql através do seguinte comando:

mysql -u root -p

O prompt bash mudou para:

mysql>

indicando que estava dentro do aplicativo cliente, conectado ao MySQL. Então executei um comando para indicar que gostaria de utilizar a base de dados mysql:

use mysql;

Após executar este comando, executei um procedimento para remoção de possíveis contas de usuário guest (convidado) e atualizar os privilégios:

DELETE FROM user WHERE user='';
FLUSH PRIVILEGES;
EXIT;

Depois de executar estes procedimentos a configuração básica do servidor MySQL na minha máquina virtual estava disponível para uso. Futuramente colocarei instruções para reforçar a segurança da base de dados.