iptables -F
iptables -F -t nat
iptables -t nat -A POSTROUTING -p ALL -s 192.168.10.0/24 -j MASQUERADE
iptables -t nat -A PREROUTING -p tcp –dport 80 -m iprange –src-range 192.168.0.100-192.168.0.190 -j REDIRECT –to-port 3128
Se você está como estive tempos atrás: irado, revolto, sem esclarecimento de como as coisas funcionam em um excelente (talvez o melhor) SGDB – Postgres e está sofrendo com os males:
1 – Encoding do Sistema Operacional Debian/Ubuntu Ferrados (sim, você brasileiro e a droga do locale te mostrando coisas de americanos, pode uma coisa destas?)
2 – Mudar o Encoding do Postgres.
Vamos ao ataque
Antemão você precisa saber que o seu sistema foi configurado por algum bestão, isto mesmo, o cara instalou o sistema americano sendo brasileiro.
Ter um porstgres que não aceita nem a pau um encoding diferente (padrão dessa tosquisse sempre é UTF8).
Locale do Sistema
Mãos-a-Obra
Todas as configurações e comandos foram executados como usuário root.
Existem vários arquivos que fazem a configuração do locale, precisamos configurar todos eles e depois executar alguns comandos, vamos lá.
Edite o arquivo /etc/environment e altere os campos LANG e LANGUAGE de forma que fiquem iguais ao abaixo, se não existir, acrescente:
LANG="pt_BR"
LANGUAGE="pt_BR:pt:en"
O arquivo /etc/default/locale também deve ser editado e seu conteúdo deve ser:
LANG="pt_BR"
LANGUAGE="pt_BR:pt:en"
Execute o seguinte comando:
# echo "pt_BR pt_BR.ISO-8859-1" >> /etc/locale.alias
Este arquivo grava os aliases para os locales, isso é para facilitar as configurações.
No diretório /var/lib/locales/supported.d alguns arquivos que configuram os locales que serão gerados, por padrão existem três arquivos “en”, “pt” e “local”. Para nosso caso, pode apagar o “en” e o “pt” deixando apenas o “local”.
Feito isso, edite o arquivo local e deixe seu conteúdo como abaixo:
pt_BR.ISO-8859-1 ISO-8859-1
en_US.ISO-8859-1 ISO-8859-1
Muito bem, configuramos os arquivos necessários para a geração dos locales, agora vamos reconfigurar.
Os comandos abaixo fazem o serviço:
# localedef pt_BR -i pt_BR -f ISO-8859-1
# localedef pt_BR.ISO-8859-1 -i pt_BR -f ISO-8859-1
# localedef pt_BR.ISO8859-1 -i pt_BR -f ISO-8859-1
# dpkg-reconfigure locales
# locale-gen --purge
# locale-gen
###### SE HOUVER ERRO USE:
localedef pt_BR -i pt_BR -f UTF-8
localedef pt_BR -i pt_BR -f LATIN1
Acredito que apenas um desses três comandos fariam o serviço, mas como eu executei os três quando estava configurando o sistema não vou tirar algum deles, é melhor executar a mais e funcionar do que executar a menos e não funcionar.
Reinicie o sistema e execute o comando abaixo para termos certeza que está tudo conforme o desejado.
# locale
LANG=pt_BR
LANGUAGE=pt_BR:pt:en
LC_CTYPE="pt_BR"
LC_NUMERIC="pt_BR"
LC_TIME="pt_BR"
LC_COLLATE="pt_BR"
LC_MONETARY="pt_BR"
LC_MESSAGES="pt_BR"
LC_PAPER="pt_BR"
LC_NAME="pt_BR"
LC_ADDRESS="pt_BR"
LC_TELEPHONE="pt_BR"
LC_MEASUREMENT="pt_BR"
LC_IDENTIFICATION="pt_BR"
LC_ALL=
# locale -a
C
en_US.iso88591
POSIX
pt_BR.iso88591
Agora sim, está tudo como deveria estar. Nosso sistema já está usando ISO-8859-1.
(ISO-8859-1é LATIN1)
Corrigindo o Encoding do Postgres
Bem, esta é a hora do quebra-quebra, vamos lá:
1 – Crie uma nova instância (cluster) de gestão do Postgres:
sudo pg_createcluster -e LATIN1 -d /caminho/do/novoSGDB 8.3
cluster-8.3-2
Feito isto, a porta que o postgres vai operar neste novo SGDB será 5433
Criando SuperUser para administrar o Postgres
[root@srv:~] # su – postgres
[postgres@srv:~] $ createuser -P
Digite o nome da role a ser adicionada: pglinux
Digite a senha para a nova role:
Digite-a novamente:
A nova role poderá criar um super-usuário? (s/n) s
CREATE ROLE
Quer ver os users?
[postgres@srv:~] $ psql
postgres=# \du
Lista de roles
Nome da role | Super-usuário | Cria role | Cria BD | Conexões | Membro de
————–+—————+———–+———+———–+———–
pglinux | sim | sim | sim | ilimitado |
postgres | sim | sim | sim | ilimitado |
(2 registros)
postgres=# \q
Informações complementares:
http://www.forumdebian.com.br/topico-1583-15.html&sid=64f758c828b395f96e7ae61b4d55897a
http://under-linux.org/7954-configurando-locale-iso-8859-1-no-kubunt-710-gutsy-gibbon.htmlE:
Este é um pequeno artigo que tem a intenção de resumir , para iniciantes no assunto, como eu, as principais funcionalidades e conceitos por trás do controle de versão (versionamento) feito através do Subversion ou SVN.
Atenção! Este artigo foi todo baseado no UBUNTU, mas pode ser facilmente modificado para se aplicar em qualquer S.O, como o windows.
Como o título pode sugerir, não pretendo aqui abordar as inúmeras funcionalidades ou mesmo mostrar todo o poder do subversion. Sou um programador PHP que, a maioria do tempo, trabalho sozinho nos meus projetos, apenas sendo ajudado no que tange ao projeto gráfico dos sites pelos meus amigos.
A idéia é mostrar como usar, de forma prática, o controle de versão, por pessoas como eu, que não obrigatoriamente estão trabalhando em grandes equipes. Deixando claro que, os conceitos aqui apresentados, poderão ser extendidos.
Começemos pelo começo !
Para que serve este negócio de controle de versão ?! A finalidade é dar um controle maior sobre tudo que você altera no seu projeto!
Pausa para explicação!
Projeto: Nome que inventamos de dar a um monte de arquivo e diretório junto! Ou seja, para o Subversion é tudo arquivo e diretório! Problema seu se você quis chamar isso de projeto!
Digamos que ele permite você ter um histórico de tudo que você fizer. Se você modificou aquela rotina para otimizar uma
consulta, se você inseriu uma nova função e retirou outra, se você modificou a imagem que era exibida em determinada página html, tudo fica lá guardado! Pra que isso ? Para o caso de sua alteração causar algum problema! Se deu você nem precisa se preocupar em relembrar o que foi que tinha alterado, se fez tudo correto, basta um simples comando e você recupera o estado anterior.
O Melhor de tudo, na minha opinião, é que você fica livre para mexer como quiser no seu projeto sem precisar ficar fazendo backups !
Vai me dizer que você nunca pegou um arquivo fonte para alterar aquela função vital e só por via das dúvidas fez um backup e deixou lá : arquivoFonte.bkp. Ai depois precisou fazer outra alteração, e lá foi você fazer um outro backup : arquivoFonte-20070507.bkp ?! Ou ainda resolveu fazer uma alteração substancial em várias partes do site e ai resolveu, por via das dúvidas, copiar todo o diretório e criar um outro: projetoBackup ! Nunca fez isso ? Sorte sua amigo, pois muita gente faz isso e fica com aquele monnnte de arquivos no diretório.
Vamos só explicar, antes de mais nada, alguns conceitos.
<conceitos>
Repositório!
Segundo o Houaiss, lugar onde se guarda, arquiva, coleciona alguma coisa. Traduzindo. Nada mais é do que o local onde você vai guardar o seu projeto. Na prática, é um diretório, uma pasta qualquer guardada ou no seu computador, ou no seu pendrive, ou em um server na china.
Repositório = Diretório = Pasta
A única diferença entre um repositório e um diretório qualquer do seu disco, é que o repositório é uma pasta que é controlada pelo Subversion, ou seja, ele vai colocar um bocado de coisa lá dentro e vai controlar tudo. Logo, não se preocupe se você não entender o que tem lá dentro. Simplesmente saiba que ele vai controlar tudo direitinho.
Cópia de Trabalho (Working Copy)
Novamente, nada mais é que um Diretório, pasta, qualquer.
Comece a perceber que,para o subversion, tudo se resume a diretórios (pastas) e arquivos. Este negócio de repositório, Cópia de Trabalho, Projeto, é tudo criação da sua cabeça.
A única diferença deste diretório para o Repositório, é que é neste que você trabalha, ou seja, faz as modificações, cria, apaga as coisas. O outro (repositório), é o seu Backup, para onde você manda, por segurança, tudo que você alterou, criou, apagou.
Se tudo é Diretório, qual a diferença entre um diretório qualquer do meu HD, para o Repositório e para a Cópia de Trabalho ? A única diferença é que o Subversion tem controle sobre estas duas últimas, não fazendo a mínima idéia do que fazer sobre todas as outras!
</conceitos>
Resumão!
Tudo se resume a pegar os arquivos do repositório (como quem tira os cadernos da gaveta), fazer as alterações necessárias, enviar de volta para o repositório (guardar os cadernos novamente). E assim sucessivamente.
Vamos Detalhar um pouquinho melhor!
Lembre-se: Você vai trabalhar em um diretório, que chamamos de Cópia de Trabalho (Working Copy) !
O funcionamento básico do controle de versão, resumidamente, consiste em:
Criou o Supusitório? Opa, é repositório rapá!
(SVNADMIN CREATE)
Caso ainda não exista uma pasta no seu computador, no seu pendrive, em um servidor qualquer da china, é hora de criar o repositório. Claro, você só vai criar se você tiver este poder né mesmo! A Idéia deste artigo é mostrar como isso é feito localmente, na sua máquina mesmo. Caso necessite, existem servidores pagos e gratuitos , como o projeto OpenSVN (https://opensvn.csie.org/) que permite que você tenha um repositório longe do seu computador.
Para criar um repositório, você vai utilizar o comando svn create. Como a idéia aqui é mostrar como utlizar o subversion, do ponto de vista , de um programador que trabalha sozinho, este passo será necessário. A não ser que se escolha utilizar um servidor externo.
O processo é simples. Basta digitar :
$svnadmin create <CaminhoDoDiretorio>
Este comando irá criar o Diretório que será considerado o repositório do seu projeto.
Eu tou começando a usar o meu pendrive como repositório. Isso mesmo. Crio o meu repositório no meu pendrive, e ele vai comigo para onde eu quiser. Quando eu chego em outro micro, plugo o pendrive, faço um checkout (explicado mais abaixo), trabalho do jeito que eu quero, e no final, basta desplugar o mesmo, clocar no bolso e ir pra casa. Qual a vantagem disso em relação a um servidor externo ? Boa pergunta! Velocidade, e acesso aos meus projetos, mesmo emmicros sem acesso a internet. Qual a desvantagem ? A inicial é que só eu posso usar isso, ou seja, se quiser um repositório compartilhado com mais pessoas, não dá.
Exemplo Prático:
$mkdir /home/diego/repositorio
$svnadmin create /home/diego/repositorio/sitePessoal
Vai começá ? Coloque as coisa sob o chicote do seu Subversion!
(SVN IMPORT)
Uma vez que o repositório esteja criado, ou tenha sido escolhido, deve-se pegar os arquivos do seu projeto, que deverão estar em uma pasta qualquer, e colocar no mesmo, para que o subversion possa começar a controlar as alterações que você fizer! Imagine isso como um Backup inicial de tudo que você já tem ou não tem.
Pausa para alguns conceitos!
O pessoal que trabalha com Controle de Versão, adora definir algumas coisas como “boa prática” ou mesmo como “regras”, mas nada disso que vou falar abaixo, é obrigatório de ser utilizado.
Como já vimos anteriormente a única coisa que o subversion entende são arquivos e diretórios, logo pouco importa o nome que damos a eles, ok ?
O “Povo”, que utiliza o subversion, defende duas correntes. Uma diz que você deve criar um repositório (Diretório) para cada projeto. Assim:
RepositorioAplicacao1
RepositorioAplicacao2
E outra que você deve ter um único repositório (diretório), guardando vários projetos. Assim:
Repositorio
+——- Aplicacao1
‘——– Aplicacao2
E ai, qual usar ? Bem, pra mim, tanto faz. O Subversion só entende diretórios mesmo. Claro, isso no entendimento básico. Como não sou nenhum expert, me parece que tem sim diferença quando você começa a usar permissionamento de quem pode mexer em que.
Outra é que, independente de como você escolheu acima, deve, ao criar o seu repositório ,estruturá-lo através de 3 diretórios, assim:
RepositorioAplicacao
+——— trunk
+——— branchs
‘———- tags
Pra que isso ? E eu sei lá! Brincadeira! Explico.
Bem, isso é muito utilizado quando você tem uma aplicação de médio/grande porte onde você tem vários desenvolvedores ou mesmo naquelas que você tem previsão de muitos versões. A idéia aqui é dividir para facilitar.
No diretório trunk deve-se colocar o projeto inicial. Seria o que o pessoal chama de linha de desenvolvimento padrão. Você começa por ai e desenvolve tudo ai dentro.
Se por um acaso você (ou outro desenvolvedor) decide, de repente, adicionar uma funcionalidade revolucionária que não estava prevista no projeto como por exemplo, a implementação de uma comunicação audio/visual em tempo real para habitantes de outros planetas, a idéia é que você faça isso em uma branch! Ou seja, você copia o estado atual da sua aplicação, ou seja, copia os arquivos todos, que estão no diretório trunk para um subdiretório dentro de branch, por exemplo, vers_comunicador_marte. Por que isso ? Porque imagine que você decida fazer isso na linha principal de desenvolvimento, ou seja, no diretório trunk. O que pode acontcer ? Pode acontecer de, por isto tudo ser um teste, quebrar a aplicação. Se você separa em um outro diretório, neste caso, um subdiretório dentro de Branch, você pode testar a vontade, sem pertubar os outros, concorda ?! Então é isso! :D
Quer ver outra explicação porquê você deve fazer uma cópia dentro do branch ? Imagine que você esteja desenvolvendo a sua aplicação, digamos versão 1.0, e ai decide que vai começar a versão 2.0, que terá umas funcionalidades malucas, mas não quer deixar de dar suporte na versão 1.0, que é a que todo mundo usa. O que você faz ? Você continua com o desenvolvimento normal, da versão 1.0, dentro do trunk, e cópia tudo para um subdiretório, por exemplo, versao2, dentro do branch, e começa a trabalhar nesta nova versão lá. Sacou ?
Beleza! E o diretório tags ?! Bem, este diretório é utilizado para criar um snapshot, um instantâneo da sua aplicação. Como assim ? Quando o pessoal vai desenvolvendo uma aplicação e vem corrigindo bugs, adicionando funcionalidades extras, etc, geralmente o que fazem é dar nomes ou números a estas versões , correto ? Por exemplo: aplicacao_ver_1.0, aplicacao_ver_1.1, etc.
A questão é, como será que você faria para distribuir esta aplicação ? Bem, você faria uma cópia da sua aplicação naquele exato momento que você definiu como uma nova versão, empacotaria e pronto! Estaria feito a versão 1.XX.YY, ok ? E se daqui a duas semanas, resolvesse que deveria lancar uma outra versão que corrigisse uns bugs, faria a mesma coisa, correto ? Bem, a idéia aqui é a mesma. Só que você vai deixar o subversion controlar isso pra você.
O que o pessoal faz, e você vai fazer, se quiser claro, é, quando decidir que uma aplicação deve ter uma nova versão lançada, você vai e copia tudo, todos os seus arquivos, diretórios, etc, para um subdiretório dentro de Tags, como por exemplo, versao1.1. E se daqui a duas semanas decide que vai lançar outra versão, cópia tudo de novo para um outro diretório, dentro de Tags, chamado versao1.2, ok ?
A questão é que, quando você acessar o diretório trunk, você terá o desenvovimento principal da sua aplicação, ou seja, o que você vem mexendo no dia a dia.
Quando você acessar um subdiretório dentro de branch, você estará acessando uma versão que você ainda está desenvolvendo e testando. É uma outra linha de desenvolvimento.
E dentro de tags, você terá instantâneos da sua aplicação em momentos que você definiu, sacou ?
E ai você pode perguntar. Beleza, tudo bem, fica tudo muito organizado, mas já imaginou a quantidade de arquivos que eu vou ter na minha máquina ? Um bocado, repetido em tudo que é canto ! Ai que está. O Subversion controla tudo isso de maneira magistral, só copiando o que deve ser copiado e fazendo links simbólicos internos ,etc, etc, etc. Ou seja, você terá o mínimo de arquivos duplicados.
Resumo da história. Tudo isso é apenas convensão para sua organização. Se você não quiser. Não precisa criar diretório trunk ou branch ou tag ou qualquer outro. Como falei antes, o Subversion entende apenas diretórios e arquivos, ou seja, para ele, trunk, branchs, tags são apenas diretórios, você ou quem utiliza que convenciona como vai utilizá-los. Isso é tão verdade, que se você quiser, nem precisa criá-los ou pode até criá-los com outros nomes, por exemplo: Em vez de trunk, colocar LinhaPrincipal, em vez de Branchs, LInhasDeTestes e em vez de Tags, VersoesLancadas.
E isso se aplica a desenvolvimento de sites ? Bem, ai é com vocês! Se achar que se aplica, utilize para organizar melhor as coisas, se não, esqueça e pronto. Só Lembre-se: TUDO É DIRETÒRIO e OPERAÇÕES DE BACKUP.
E depois de tudo isso, o que eu devo fazer, pelo amor de Deus ?
Bem, se você quiser utilizar o que falei acima, ou seja, utilizar estas convenções, crie os diretórios trunk, branchs, tags, coloque toda a sua aplicação (arquivos fontes, diretórios, etc) dentro do trunk, e importe tudo para o repositório. Este ato de importar, está indicando para o subversion que ele deve copiar tudo que está na sua pasta para o seu repositório e deve começar a controlar as coisas.
Continuando o Exemplo Prático:
Continuando o exemplo anterior
$cd /home/diego/temp
$mkdir MinhaAplicacao
$mkdir MinhaAplicacao/trunk
$mkdir MinhaAplicacao/branchs
$mkdir MinhaAplicacao/tags
$cd MinhaAplicacaoObservação: Caso você já tenha algo desenvolvido do seu projeto, conforme a convenção explicada acima, coloque tudo dentro do diretório trunk.
$svn import . file:///home/diego/repositorio/sitePessoal/trunk/
Observação2: Estou utilizando, nos exemplos, um repositório local, que fica na mesma máquina. Como dito anteriormente, o mesmo pode estar em um servidor remoto, e ai o acesso pode se dar pelo protocolo http. Neste caso você utilizaria, no lugar de file://, http://<servidor>/<Repositorio>
Atente para o fato de que, mesmo estando na mesma máquina, o acesso ao repositório, feito pelo svn, é através de uma URL, neste caso file://.
E esse tar de Uorqui Copí ?!
(SVN CHECKOUT)
Como explicado anteriormente, o subversion só controla dois diretórios: O repositório e a Cópia de Trabalho. É necessário, caso você ainda não possua, criar uma cópia de trabalho. Isso nada mais é do que pegar o que tem no seu repositório, ou seja, seu backup, e colocar em uma pasta qualquer. A partir deste momento, você terá uma cópia de trabalho do seu projeto, onde deverá efetuar todas as alterações.
Atenção! Atenção! LEIA RAPÁ !
Quando você faz o IMPORT do seu projeto para o repositório, como explicado no item anterior, o diretório não fica automaticamente controlado pelo Subversion! Por isso ele pode ser descartado, apagado, jogado fora, esquecido, deletado. Entendeu ?
Logo, para começar a trabalhar no seu projeto, depois de importá-lo para o repositório, é obrigatório que você faça um checkout, ou seja, copie tuuuuudo de volta, do repositório para algum diretório (work copy).
Este processo de checkout é sempre utilizado quando se vai começar a trabalhar no projeto, caso você não possua uma cópia de trabalho (work copy), em sua máquina ou em uma máquina nova. Caso já possua, geralmente se faz um update apenas, que tratará de atualizar a sua versão da cópia de trabalho de acordo com a que está no repositório.
Também é utilizado, quando você quer pegar uma versão qualquer do seu projeto, que não a última, ou mesmo, uma versão que está em algum branch.
Continuando o exemplo prático
$mkdir /home/diego/projetos/CopiaTrabalhoSitePessoal
$cd /home/diego/projetos/CopiaTrabalhoSitePessoal
$svn checkout file:///home/diego/repositorio/sitePessoal/trunk/Caso você queira trabalhar em um branch específico, por exemplo, uma versão 2 que você está desenvolvendo, em vez da linha de desenvolvimento principal:
$svn checkout file:///home/diego/repositorio/sitePessoal/branchs/ver2
Não sei se vocês notaram, mas até agora, tudo se resumiu a copiar de um diretório para outro, só que ao invés de usar comandos do sistema operacional, estamos usando o subversion.
Alterô os Arquivo ?! Ouxe, Diz pro Seu Subversion cuidá dêles.
(SVN COMMIT)
Toda e qualquer alteração na sua cópia de trabalho não é automaticamente controlada pelo subversion! Não? Não! Uma vez que você tenha alterado um arquivo, você precisa dizer para o subversion que você alterou e que ele deve ser enviado para o repositório!
Opa! Perai! Mas se o repositório é um backup, ele vai apagar meu backup anterior! Naaada disso! Ai é onde está o pulo do gato. O Subversion, não apagar nunca seus arquivos, apenas ele vai criar uma nova versão do seu arquivo lá! Ou seja, vai existir a cópia anterior e a nova cópia! :D Isso é o que se chama de revisão. Toda vez que você altera algo e manda para o repositório, você está criando uma nova revisão.
Continuando o exemplo prático
$cd /home/diego/projetos/CopiaTrabalhoSitePessoal
$svn commit file:///home/diego/repositorio/sitePessoal/trunk/
Criô ? Apagô ? Tá bulindo nas coisa né ? Vô dizê pro Seu Subversion!
(SVN ADD, DELETE, MKDIR, etc)
Assim como as alterações nos arquivos, quando você cria um novo diretório dentro do seu projeto, apaga, mude de lugar, ou seja, mexe na estrutura do seu projeto, você precisa informar isso para o Subversion.
Tudo isso é feito através dos comandos ADD, DELETE, MKDIR, etc. Veja abaixo, no Exemplo Prático da Vida Real, como trabalhar com estes comandos.
E se eu já tô cum minha Uorqui Copi, como qui eu dexo ela atualizadinha ?
(SVN UPDATE)
Isso é feito através do comando UPDATE, que tem a finalidade de atualizar a sua cópia de trabalho.
E como é que se mexe nestes tar de BRUNCH, TAG ?
Quer saber mesmo ? Então veja o Exemplo Prático da Vida Real abaixo. É facim facim.
1. Criando o Repositório em uma pasta qualquer
/tmp# mkdir repositorios
/tmp# cd repositorios/
/tmp/repositorios# svnadmin create HelloWord
/tmp/repositorios# ls -lhtotal 4,0K
drwxr-xr-x 7 root root 4,0K 2007-05-29 09:31 HelloWord/tmp/repositorios# ls -lh HelloWord/
total 28K
drwxr-xr-x 2 root root 4,0K 2007-05-29 09:31 conf
drwxr-xr-x 2 root root 4,0K 2007-05-29 09:31 dav
drwxr-sr-x 5 root root 4,0K 2007-05-29 09:31 db
-r–r–r– 1 root root 2 2007-05-29 09:31 format
drwxr-xr-x 2 root root 4,0K 2007-05-29 09:31 hooks
drwxr-xr-x 2 root root 4,0K 2007-05-29 09:31 locks
-rw-r–r– 1 root root 229 2007-05-29 09:31 README.txt
2. Criando o diretório e estrutura da nossa futura aplicação.
/tmp/repositorios# cd ..
/tmp# mkdir HelloWord
/tmp# cd HelloWord
/tmp/HelloWord# mkdir trunk
/tmp/HelloWord# mkdir branchs
/tmp/HelloWord# mkdir tags
/tmp/HelloWord# ls -lhtotal 12K
drwxr-xr-x 2 root root 4,0K 2007-05-29 09:38 branchs
drwxr-xr-x 2 root root 4,0K 2007-05-29 09:38 tags
drwxr-xr-x 2 root root 4,0K 2007-05-29 09:38 trunk/tmp/HelloWord# cd trunk
/tmp/HelloWord/trunk# echo “<?php echo ‘pagina inicial’; ?>” > index.php
/tmp/HelloWord/trunk# cat index.php<?php echo ‘pagina inicial’; ?>
/tmp/HelloWord/trunk# ls -lh
total 4,0K
-rw-r–r– 1 root root 32 2007-05-29 09:41 index.php
3. Importando (enviando) a aplicação para o repositório.
/tmp/HelloWord/trunk# cd ..
/tmp/HelloWord# svn import . file:///tmp/repositorios/HelloWord/ \
-m “Importacao Inicial”Adicionando branchs
Adicionando trunk
Adicionando trunk/index.php
Adicionando tagsCommit da revisão 1.
/tmp/HelloWord# ls -lh /tmp/repositorios/HelloWord/total 28K
drwxr-xr-x 2 root root 4,0K 2007-05-29 10:09 conf
drwxr-xr-x 2 root root 4,0K 2007-05-29 10:09 dav
drwxr-sr-x 5 root root 4,0K 2007-05-29 10:09 db
-r–r–r– 1 root root 2 2007-05-29 10:09 format
drwxr-xr-x 2 root root 4,0K 2007-05-29 10:09 hooks
drwxr-xr-x 2 root root 4,0K 2007-05-29 10:09 locks
-rw-r–r– 1 root root 229 2007-05-29 10:09 README.txt
Observe que a estrutura de diretórios do repositório, apesar da importação(cópia), não mudou em nada, pois o subversion trata de controlar tudo isso internamente. Era de se esperar que aparecessem as pasta s trunk, branchs, tags dentro de /tmp/repositorios/HelloWord, já que a importação nada mais é do que uma cópia não é mesmo ? ;D
Observe também que todas as operações com o subversion, de importação, de update, de checkout, etc, devem ser realizadas na raiz do projeto, neste caso o diretório /tmp/HelloWord.
4. Apagando o conteúdo do diretório, que já não é mais necessário, e que não é controlado pelo subversion, e fazendo o primeiro checkout.
/tmp/HelloWord# rm * -r
/tmp/HelloWord# svn checkout file:///tmp/repositorios/HelloWord/trunk .A index.php
Gerado cópia de trabalho para revisão 1./tmp/HelloWord# ls -lh
total 4,0K
-rw-r–r– 1 root root 32 2007-05-29 10:19 index.php
Observe que, como pedimos para fazer o checkout do trunk, veio apenas o arquivo index.php. Lembre-se, não ficaremos fazendo checkout de toda a estrutura que importamos, mas apenas do que nos interessa, ou seja, o que estiver dentro do trunk, ou de branchs ou mesmo de tags.
5. Alterando o conteúdo do arquivo e dando commit para forçar a atualização do Repositório.
/tmp/HelloWord# echo “<?php echo ‘linha2′; ?>” >> index.php
/tmp/HelloWord# cat index.php
<?php echo ‘pagina inicial’; ?>
<?php echo ‘linha2′; ?>/tmp/HelloWord# svn status
M index.php/tmp/HelloWord# svn commit -m “index.php modificado”
Enviando index.php
Transmitindo dados do arquivo .
Commit da revisão 2.
Observe que, após a edição do arquivo, ao se executar o comando svn status, o mesmo retorna indicando que o index.php foi Modificado.
Quanto se executa o commit o arquivo Modificado é enviado para o repositório e o prrojeto fica na revisão 2.
6. Alterando a estrutura (diretórios e arquivos) do projeto.
/tmp/HelloWord# mkdir cpanel
/tmp/HelloWord# cd cpanel
/tmp/HelloWord/cpanel# echo “<?php echo ‘PainelDeControle’; ?>” > \
cpanel.php
/tmp/HelloWord/cpanel# cd ..
/tmp/HelloWord# svn status
? cpanel
Observe que o subversion mostra uma interrogação ao lado do diretório que acabamos de criar. Isso indica que este diretório ainda não é controlado pelo subversion, ou seja, ainda não está no repositório. Precisamos adicioná-lo ao repositório.
/tmp/HelloWord# svn add cpanel/
A cpanel
A cpanel/cpanel.php
Observe que ele automaticamente adiciona tudo que está dentro do diretório cpanel. Vale lembrar que, apesar do comando ter sido bem sucedido, o mesmo ainda não foi definitivamente concretizado. Para isso, precisamos chamar novamente o commit.
/tmp/HelloWord# svn commit -m “+ Diretorio cpanel”
Adicionando cpanel
Adicionando cpanel/cpanel.php
Transmitindo dados do arquivo .
Commit da revisão 3.
Veja que automaticamente todo o conteúdo do diretório foi enviado ao repositório e agora o nosso projeto se encontra na revisão 3.
vamos adicionar mais um arquivo no nosso cpanel e ver o que acontece.
/tmp/HelloWord# echo “<?php echo ‘moduloUsuario’; ?>” > \
cpanel/user.php
/tmp/HelloWord# svn status
? cpanel/user.php
Como esperado, o status retorna informando que o arquivo user.php ainda não está sobre controle do subversion. Logo vamos adicioná-lo.
/tmp/HelloWord# svn add cpanel/user.php
A cpanel/user.php
/tmp/HelloWord# svn commit -m “+ modulo usuario”
Adicionando cpanel/user.php
Transmitindo dados do arquivo .
Commit da revisão 4.
Agora nosso projeto se encontra na revisão 4. Acho que você já deve ter notado que a cada commit o número da revisão é incrementado. Deve ter notado também que a cada arquivo criado, deve-se adicioná-lo ao repositório correto ? Correto! E deve estar pensando natrabalheira que é, se eu adcionar um monte de arquivos ou se eu tiver que ficar dando add e commit a cada arquivo criado. Pois é ! Mas hoje já existem aplicativos, como o rapidSVN, o TortoiseSVN(para windows), scripts que se integram ao nautilus, etc, que fazem tudo isso na interface gráfica. Ou seja, o que estamso fazendo aqui, manualmente é para que você entenda o conceito, já que o modo de usar os softwares pode variar de um para outro.
Vamos imaginar agora que por um descuido você removeu o arquivo user.php, do diretório cpanel, quando era para ter removido outro.
/tmp/HelloWord# rm cpanel/user.php
/tmp/HelloWord# svn status
! cpanel/user.php
Observe que o subversion retorna com o nome do arquivo removido com uam exclamação, como quem diz : Meu Deus, cadê o arquivo que eu estava controlando ?! Como isso foi um engano, e como você anteriormente já tinha colocado este arquivo no repositório, você pode atualizar a sua cópia de trabalho com o comando updatde.
/tmp/HelloWord# svn update
Restaurado ‘cpanel/user.php’
Na revisão 4.
O arquivo foi restaurado. Começaram a perceber o poder deste negócio de controle de versão ?
Com isso fica o que falamos acima. Quando quiser realmente adicionar um diretório, remover um arquivo, criar um novo arquivo, você deve fazer isso com os comandos do subversion. Na verdade, adicionar arquivo e diretórios nem é tão crítico, já que podemos utilizar o comando add posteriormente a criação dos mesmos, mas a remoção de arquivos e diretórios ou mesmo a movimentação deles para outros lugares, isto sim, deve ser feito com o subversion. Logo a remoção do arquivo, se você quiser realmente removê-lo, deve ser feita da seguinte maneira :
/tmp/HelloWord# svn delete cpanel/user.php
D cpanel/user.php
/tmp/HelloWord# ls cpanel -lh
total 4,0K
-rw-r–r– 1 root root 34 2007-05-29 12:23 cpanel.php
/tmp/HelloWord# svn commit -m “- user.php”
Apagando cpanel/user.php
Commit da revisão 5.
E se, mesmo depois de ter apagado propositadamente, você descobre que aquele arquivo continha um trecho que você poderia necessitar ? Ou mesmo, que aquele arquivo era essencial e você não deveria ter apagado ? Será que tem como recuperar o arquivo ? Tem sim, claro. Basta você dizer para o subversion que quer que ele atualize a sua cópia de trabalho para a revisão anterior, no caso a 4.
/tmp/HelloWord# svn update -r4
A cpanel/user.php
Atualizado para revisão 4.
/tmp/HelloWord# ls cpanel -lh
total 8,0K
-rw-r–r– 1 root root 34 2007-05-29 12:23 cpanel.php
-rw-r–r– 1 root root 31 2007-05-29 12:59 user.php
Observe que agora estamos trabalhando da revisão 4. A revisão 5 ainda existe, só que ela não possui o arquivo user.php. O interessante é notar que, a qualquer momento, podemos trabalhar nas revisões que quisermos, nos movimentando entre os nossos “backups”. Só que isso gerou um impasse, concordam ? Eu tenho um arquivo , que acabei apagando de propósito, mas que não era para ter apagado, na revisão 4, mas não tenho ele na revisão 5. Se eu continuar a trabalhar na revisão 4, eu perco todas as outras alterações (se houverem), que eu tenha feito até o commit para a revisão 5. Se eu vou para a revisão 5, eu tenho todas as alterações, mas não tenho o arquivo user.php. E agora ? Quem poderá nos ajudar ? :D
A questão é que o subversion dá nó em pingo d’água. E o que estamos escrevendo aqui é apenas uma pontinha de todo o seu poder. Como tudo para o subversion é diretório e arquivo, pensemos assim. Se eu não utiliza-se controle de versão e fizesse as coisas na mão, provavelmente eu teria dois diretórios assim :
HelloWordRevisao4
HelloWordRevisao5
Logo, ficaria muito fácil eu recuperar o arquivo, fazendo uma simples cópia entre diretórios, concorda ? Então o mesmo se aplica ao subversion, ele tem um comando chamado copy, onde você pode especificar a origem, o destino e a revisão. Então observe:
Voltemos para a revisão 5.
/tmp/HelloWord# svn update
D cpanel/user.php
Atualizado para revisão 5./tmp/HelloWord# ls cpanel/ -lh
total 4,0K
-rw-r–r– 1 root root 34 2007-05-29 12:23 cpanel.php
Agora vamos copiar o arquivo user.php, que está na revisão 4, para a nossa cópia de trabalho atual.
/tmp/HelloWord# svn copy -r4 \
file:///tmp/repositorios/HelloWord/trunk/cpanel/user.php \
cpanel/A cpanel/user.php
/tmp/HelloWord# ls cpanel/ -lh
total 8,0K
-rw-r–r– 1 root root 34 2007-05-29 12:23 cpanel.php
-rw-r–r– 1 root root 31 2007-05-29 13:13 user.php/tmp/HelloWord# svn status
A + cpanel/user.php
Como podemos notar, o arquivo foi copiado do repositório para a pasta, e aparece com um A, indicando que foi adicionado a sua cópia de trabalho. Finalmente, vamos dar um commit para gravar tudo no repositório.
/tmp/HelloWord# svn commit -m “user.php recuperado”
Adicionando cpanel/user.php
Commit da revisão 6.
Imagine que chegamos ao final do dia e decidimos que esta versão final (revisão 6) deveria sser chamada de HelloWord Versao 1.0. Podemos decorar que a revisão 6, é a versão 1.0, ou podemos dar este nome específico para esta revisão. de modo que quando fizermos referência a versao 1.0 o subversion nos traga automaticamente a revisão 6. Este processo consiste em “TAGGEAR” o projeto. Este é o motivo, já explicado acima, de termos criado o diretório tags.
Este processo nada mais é do que uma cópia entre diretórios, utilizando o subversion.
Antes de mais nada, vamos listar quais são as tags (versões já lançadas, digamos assim), que nós temos. Ou seja, vamos dar um ls (comando dir, para o DOS), no repositório.
/tmp/HelloWord# svn list file:///tmp/repositorios/HelloWord/tags/
Observe que nada foi retornado, como esperado.
Para testar um pouco mais do comando list, vamos listar o trunk.
/tmp/HelloWord# svn list file:///tmp/repositorios/HelloWord/trunk/
cpanel/
index.php
Ele retornou com os nossos arquivos. Claro, porque estamos trabalhando sempre no trunk, lembram ? Ou seja, o comando list seria como um ls, láááá no repositório.
Mas vamos lançar nossa versão 1.0 do nosso incrível projeto Hello Word.
tmp/HelloWord# svn copy file:///tmp/repositorios/HelloWord/trunk/ \
file:///tmp/repositorios/HelloWord/tags/versao1.0 \
-m “Lancando a versao 1.0″Commit da revisão 7.
Antes de mais nada, o comando acima deve ser digitado em uma única linha. Pronto, nossa versão foi lançada. O que fizemos foi apenas copiar o que tinha no nosso Trunk para o diretório versao1.0 dentro de tags. Isso láááá no nosso repositório ok ? Ah, uma coisa. Isso não vai duplicar os milhares de arquivos que temos em nosso projeto, ele vai apenas criar links simbólicos, ok ? :D
Vamos listar agora, quais as tags (versôes) que nós temos.
/tmp/HelloWord# svn list file:///tmp/repositorios/HelloWord/tags/
versao1.0/
Pronto! Final do Dia. tudo correu bem. Lançamos uma versão e vamos para casa.
Agora imagine que você chegou em casa, e lembrou que esqueceu de coloca uma pequena coisa no index.php, e gostaria de trabalhar no seu projeto. Claro, que estamos trabalhando com um repositório local, mas como dito anteriormente, o mesmo pode estar em um servidor em qualquer lugar do mundo, ou mesmo, pode estar no seu pendrive. Vamos fazer de conta, que o repositório está acessível para a gente da mesma forma que estava na outra máquina, lá no trabalho ok ?
E agora, como eu faço para trabalhar no meu projeto ? Basta você voltar a fita e ir lááááá para o passo número 4, onde falamos em checkout. É isso mesmo. Como não temos uma Cópia de Trabalho, ainda, precisamos fazer um checkout, ou seja, copiar a revisão lá do repositório para um diretório qualquer. Então você pode fazer, imaginando que vamos trabalhar no diretório /home/diego/temp :
/home/diego/temp# mkdir HelloWord
/home/diego/temp# cd HelloWord/
/home/diego/temp/HelloWord# svn checkout \
file:///tmp/repositorios/HelloWord/trunk .A cpanel
A cpanel/user.php
A cpanel/cpanel.php
A index.php
Gerado cópia de trabalho para revisão 7.
Pronto, agora é só meter a mão na massa e continur com os commits, updates, etc etc etc.
Ah, como estamos trabalhando sozinhos, os updates não se tornam tão importantes. Mas se estivermos trabalhando em dupla de dois, por exemplo, vale a pena sempre dar update para garantir que sua cópia de trabalho esteja sempre atualizada, caso seu amigo tenha feito alguma modificação.
Espero que este pequeno grande artigo sirva para abrir os horizontes dos iniciantes no mundo do controle de versão.
Fonte: http://www.ultimolog.com/2007/05/29/controle-de-versao-com-subversion-svn-rapido-e-pratico/
Estava me organizando para uma séria de projetos, nada mais justo que falar para você mesmo que você precisa ser justo com a administração de seu tempo. Estou em um domingo, descansando e disposto a dar mastigadinho (outra vez) o esquema para você:
Arena – ou campo de batalha
Bem, após passar somente 4 hs e 42 minutos levando couro do apache, pedindo “arrego” para uma figura que gosta do assunto, consegui, sem frescuras colocar para moer este “safado”. Como sempre, LÁ VAI MASTIGADINHO:
Baixe o fonte -> http://www.modsecurity.org/download/direct.html
faça:
sudo apt-get update
apt-get upgrade
sudo apt-get install apache2-prefork-dev libxml++2.6-dev liblua5.1-0 liblua5.1-0-dev libcurl3-dev
---
após, vá ao diretório aonde extraiu arquivos ou, se não, use:
tar -zxvf arquivo-do-modsec.tar.gz
cd arquivo-do-modsec.tar.gz
./configure
make && make all && make install
Após (caso haja erro de libs, instale uma por uma pesquisando antes com apt-cache search libnaoexistente) faça:
sudo vim /etc/apache2/mods-available/mod-security2.load
insira:
LoadFile /usr/lib/libxml2.so LoadFile /usr/lib/liblua5.1.so LoadModule security2_module /usr/lib/apache2/modules/mod_security2.so"linkando as coisas"sudo ln -s /etc/apache2/mods-available/mod-security2.load /etc/apache2/mods-enabledsudo ln -s /etc/apache2/mods-available/unique_id.load /etc/apache2/mods-enabledVamos editar agora:vim /etc/apache2/conf.d/modsecurity2.confinsira:<ifmodule mod_security2.c> Include /etc/modsecurity/*.conf </ifmodule>"Criando as coisas"sudo mkdir /etc/modsecurity sudo mkdir /etc/modsecurity/logs sudo touch /etc/modsecurity/logs/modsec_audit.log sudo touch /etc/modsecurity/logs/modsec_debug.logsudo cp *.conf /etc/modsecurity/"ajustes finais"sudo vim /etc/modsecurity/modsecurity_crs_10_config.confInforme:SecDebugLog /etc/modsecurity/logs/modsec_debug.log SecAuditLog /etc/modsecurity/logs/modsec_audit.log
“Finish”
sudo /etc/init.d/apache2 restart
cat /var/log/apache2/error.log | grep “ModSecurity for”
Interfaces de Rede Loucas no Ubuntu e Debian levantando muitas placas de redes
A ordem das placas é determinada pela ordem em que é carregado os modulos em /etc/modules, pelo definido nos aliases e pela ordem fisica das placas nos slots.
adicionando aliases:
# touch /etc/modprobe.d/net
# mcedit /etc/modprobe.d/net
digite :
alias eth0 <modulo_da_placa1>
alias eth1 <modulo_da_placa2>
Use lsmod para listar os módulos carregados.
Esse tutorial eu vou explicar como você pode configurar a rede no ubuntu todos os sabores (K) (X) (E), e debian todos os sabores. Irei mostrar os principais arquivos de configuração e os principais comandos de rede.
Lembrando que no debian você deve substituir o comando sudo pelo su -c ‘comando dentro das aspas’ .
O linux a sua rede funciona no modo texto, diferente do Windows que é modo gráfico , e sua configuração fica dentro de arquivos texto, no qual você pode manipular esses arquivos de acordo com a sua finalidade, é importante para qualquer usuário de linux saber como se pode configurar uma rede em modo texto, pois pode existir situações que só vai existir o modo texto.
Primeiro vamos saber os principais Arquivos da rede.
Todos os principais arquivos de configuração do Linux fica dentro do diretório /etc .
O arquivo resolv.conf , esse arquivo fica o endereço de IP do seu servidor de DNS .É bom se ter um bom servidor de DNS pois quando você usa um servidor ruim sua rede pode ficar Lenta , você pode encontrar no site do abusar alguns endereços de servidores http://www.abusar.org/dns.html . No meu caso estou usando um servidor de DNS local na minha rede.
/etc/resolv.conf seu conteúdo nameserver 192.168.254.40
O arquivo hosts , fica a informação do nome da sua máquina e você pode colocar um nome de uma máquina dentro da sua rede que você pode criar um apelido para ela , e acessar ela no seu navegado.
/etc/hosts
Conteúdo
127.0.0.1 localhost
127.0.1.1 xjulio.com julio-not
192.168.254.40 xjulio.com http://www.xjulio.com# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
O arquivo interfaces fica dentro do diretório /etc/network, esse arquivo armazena a configuração das suas interfaces de rede, nele você manipula a forma que sua rede se comporta , você pode escolher em deixar sua interface como dhcp ou como ip stático , e também pode criar ip alias . “IP alias é uma apelido que você pode dar a sua interface de rede na qual você pode atribuir outros endereços de rede, você pode criar quantos ip alias desejar”.
/etc/network/interfaces
O conteúdo do meu arquivo.
auto lo
iface lo inet loopback
address 127.0.0.1
netmask 255.0.0.0iface eth0 inet static
address 192.168.254.55
net 192.168.254.0
netmask 255.255.255.0
gateway 192.168.254.254
Os principais comandos de rede são:
ifconfig , ifup, ifdown, route, iwconfig , dhclient.
Usando o dhclient para pegar ip por dhcp.
sudo dhclient eth0
Atribuindo um endereço de ip a uma interface de rede usando ifconfig .
sudo ifconfig eth0 192.168.254.50 netmask 255.255.255.0
Atribuindo um ip alias a uma interface de rede usando ifconfig, no lugar do 1 você pode colocar qualquer nome ou numero.
sudo ifconfig eth0:1 192.168.0.30 netmask 255.255.255.0
Listando as interfaces existentes usando ifconfig .
sudo ifconfig
Derrubando uma interface usando ifconfig.
sudo ifconfig eth0 down .
levantando uma interface usando ifconfig.
sudo ifconfig eth0 up .
Agora usando o ifup e ifdown.
Derrubar todas as interfaces e seus endereços de ip.
sudo ifdown -a
Levantando todas as redes de acordo com os dados do arquivo /etc/network/interfaces
sudo ifup -a .
Agora usando o comando route. O comando route define a rota ou a interface padrão da sua placa de rede.
Para saber as rotas existentes na sua maquina use esse comando.
netstat -r
Atribuindo o gateway padrão da sua rede usando o comando route .
sudo route add default gw 192.168.254.254
Atribuindo uma interface como padrão.
sudo route add default ppp0
Agora vamos configurar a nossa rede usando o arquivo /etc/network/interfaces
Configurando a rede como DHCP padrão na interface eth0 .
sudo nano /etc/network/interfaces
coloque
auto eth0
iface eth0 inet dhcp
Configurando a interface eth0 com ip estático.
sudo nano /etc/network/interfaces
#coloque de acordo com sua rede.
auto eth0
iface eth0 inet static
address 192.168.254.55
net 192.168.254.0
netmask 255.255.255.0
gateway 192.168.254.254
Configurando sua rede como ip alias estático .
sudo nano /etc/network/interfaces
#coloque de acordo com sua rede.
auto eth0:1
iface eth0:1 inet static
address 192.168.0.55
net 192.168.0.0
netmask 255.255.255.0
gateway 192.168.254.254
Depois de configurar o arquivo derrube as interfaces.
sudo ifdown -a
Depois levante .
sudo ifup -a
Para reniciar a sua configuração de rede existe esse comando.
sudo /etc/init.d/networking restart
Fonte: http://www.xjulio.info/blog/configurando-a-rede-na-linha-de-comando-no-ubuntu-e-no-debian
A monstruosa Google nem perdeu tempo e já disponibilizou seu navegador Ultraleve e UltraFuncional. Vale a pena ressaltar que há pouco tempo ela estava apoiando o firefox (projeto mozilla) que por sua vez está na versão 3. Não iremos comentar, iremos disponibilizar (liberado há poucos minutos) o link para download, por isso “voe”:
A notícia foi retirada de -> www.tinews.info
Little_Oak 