Skip to content
AppUnix

Tag: howto

Como instalar Nginx PHP5 e Mysql no CentOS 5.6

08/08/2011 by OwnServer

A pronúncia correta do Nginx é “engin-ex”, mas vamos nos ater aos comandos que é o melhor que podemos fazer, né? NÃO sem antes falar que essa besteirinha segura “somente” milhões de acessos por dia ao site WordPress, por isso CONFIE e USE nginx sem QUALQUER medo! (existe plugin pago e grátis para o Cpanel, mas recomendamos que use o plugin free sob CENTOS senão seu cpanel vai sobrescrever os confs de vhosts do nginx).

Primeiro estou imaginando que seu ip será igual o meu -> 10.0.0.1.

Vamos instalar o Mysql?

root@appunixlabs:# yum clean all && yum update -y && yum install mysql mysql-server -y

O -y acima manda o yum instalar as coisas sem pedir confirmações.

Assim que terminarmos a instalação deveremos dar autoridade ao mysql para que possa iniciar assim que o server for inicializado (estilo pós reboot :P ):

root@appunixlabs:# chkconfig –levels 235 mysqld on

E vamos inicializar o bichão:

root@appunixlabs:# /etc/init.d/mysqld start

Se quisermos verificar se a porta do Mysql está aberta (funcionando) podemos usar o netstat -tap | grep mysql.

Agora precisamos editar o conf do mysql para deixar a conectividade dele filé:

root@appunixlabs:# vim /etc/my.cnf

Devemos achar a linha skip-networking e colocar um sinal de libra (#) para comentar essa instrução:

#skip-networking

Podemos localizar este termo usando / e digitando skip-networking no modo comando do vim (basta apertar o ESC e depois apertar /).

Vamos validar o trem?

root@appunixlabs:# /etc/init.d/mysqld restart

Devemos agora aplicar as correções de segurança do Mysql para desativar test user, definir senha de root… Bora simbora?

root@appunixlabs:# mysql_secure_installation

NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MySQL
SERVERS IN PRODUCTION USE! PLEASE READ EACH STEP CAREFULLY!

In order to log into MySQL to secure it, we’ll need the current
password for the root user. If you’ve just installed MySQL, and
you haven’t set the root password yet, the password will be blank,
so you should just press enter here.

Enter current password for root (enter for none):
OK, successfully used password, moving on…

Setting the root password ensures that nobody can log into the MySQL
root user without the proper authorisation.

Set root password? [Y/n] < – APERTE ENTER New password: <– DIGITE A SENHA DE ROOT DO MYSQL Re-enter new password: <– REPITA A SENHA DE ROOT DO MYSQL Password updated successfully! Reloading privilege tables.. … Success! By default, a MySQL installation has an anonymous user, allowing anyone to log into MySQL without having to have a user account created for them. This is intended only for testing, and to make the installation go a bit smoother. You should remove them before moving into a production environment. Remove anonymous users? [Y/n] <– ENTER PARA CONFIRMAR … Success! Normally, root should only be allowed to connect from ’localhost’. This ensures that someone cannot guess at the root password from the network. Disallow root login remotely? [Y/n] <– ENTER PARA CONFIRMAR … Success! By default, MySQL comes with a database named ’test’ that anyone can access. This is also intended only for testing, and should be removed before moving into a production environment. Remove test database and access to it? [Y/n] <– ENTER PARA CONFIRMAR - Dropping test database… … Success! - Removing privileges on test database… … Success! Reloading the privilege tables will ensure that all changes made so far will take effect immediately. Reload privilege tables now? [Y/n] <– ENTER PARA CONFIRMAR … Success! Cleaning up… All done! If you’ve completed all of the above steps, your MySQL installation should now be secure. Thanks for using MySQL!

Hora de instalarmos o Nginx, bora simbora? Pera! Antes de irmos temos de ajustar o repositório primeiro, para isto temos de fazer o seguinte:

root@appunixlabs:# cd /etc/yum.repos.d/

root@appunixlabs:# wget http://centos.karan.org/kbsingh-CentOS-Extras.repo

Pronto, precisamos agora somente editar o conf do repositório extra:

root@appunixlabs:# vim /etc/yum.repos.d/kbsingh-CentOS-Extras.repo

Precisamos deixar nosso conf parecido com este:

# pkgs in the -Testing repo are not gpg signed
[kbs-CentOS-Testing]
name=CentOS.Karan.Org-EL$releasever - Testing
gpgcheck=0
gpgkey=http://centos.karan.org/RPM-GPG-KEY-karan.org.txt
enabled=1
baseurl=http://centos.karan.org/el$releasever/extras/testing/$basearch/RPMS/

No gpgcheck temos de deixar 1.

Salvando e saindo do arquivo iremos deixar a casa arrumada:

root@appunixlabs:# yum update && yum install nginx -y

Agora teremos de colocar o nginx com direito de iniciar-se no momento do boot do server e depois disto validar este parâmetro:

root@appunixlabs:# chkconfig –levels 235 nginx on
root@appunixlabs:# /etc/init.d/nginx start

Para conferirmos que ficou filé basta abrir o navegador e digitar http://10.0.0.1, isto vai mostrar o container moendo :P.

Agora precisamos instalar o php, integrá-lo e ativar o suporte fastcgi. Para isto iremos abusar do yum (pra variar):

root@appunixlabs:# yum install lighttpd-fastcgi php-cli php-mysql php-gd php-imap php-ldap php-odbc php-pear php-xml php-xmlrpc php-mbstring php-mcrypt php-mssql php-snmp php-soap php-tidy -y

Agora precisamos editar o php.ini para dar suporte ao fastcgi:

root@appunixlabs:# vim /etc/php.ini

No padrão cgi.fix_pathinfo = 0 deixe cgi.fix_pathinfo = 1 (use a localização do vim a qual citamos neste post).

Vamos inicar agora o suporte ao FastCgi do PHP na porta 9000:

root@appunixlabs:# /usr/bin/spawn-fcgi -a 127.0.0.1 -p 9000 -u nginx -g nginx -f /usr/bin/php-cgi -P /var/run/fastcgi-php.pid

Agora devemos colocar essa instrução junto ao rc.local pra o bicho iniciar sozinho no momento do boot:

root@appunixlabs:# vim /etc/rc.local

Coloque isto no arquivo: /usr/bin/spawn-fcgi -a 127.0.0.1 -p 9000 -u nginx -g nginx -f /usr/bin/php-cgi -P /var/run/fastcgi-php.pid

Precisamos corrigir o keepalive do conf do nginx e mais coisas :(.

[ ... início do arquivo ... ]
worker_processes 5;
[... meio do arquivo ...]
keepalive_timeout 2;
[... fim do arquivo ...]

Precisamos criar o nosso default host :P, para isto temos de mudar a área do container do server:

server {
listen 80;
server_name _;

#charset koi8-r;

#access_log logs/host.access.log main;

location / {
root /usr/share/nginx/html;
index index.php index.html index.htm;
}

error_page 404 /404.html;
location = /404.html {
root /usr/share/nginx/html;
}

# redirect server error pages to the static page /50x.html
#
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/share/nginx/html;
}

# proxy the PHP scripts to Apache listening on 127.0.0.1:80
#
#location ~ \.php$ {
# proxy_pass http://127.0.0.1;
#}

# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
#
location ~ \.php$ {
root /usr/share/nginx/html;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /usr/share/nginx/html$fastcgi_script_name;
include fastcgi_params;
}

# deny access to .htaccess files, if Apache's document root
# concurs with nginx's one
#
location ~ /\.ht {
deny all;
}
}

server_name é a parte que valida nome canônico (www.qualquercoisa.com.br)
location / adicionamos index.php como sendo prioridade na abertura de arquivos (o default da vida).
A pasta de arquivos (o que seria um public_html ou www, ou ainda um httpdocs da vida) é /usr/share/nginx/html. (document root)
O principal deste arquivo é esta parte -> location ~ \.php$ {}, devemos descomentar a mesma para que esteja validada.
Se não mudarmos fastcgi_param para fastcgi_param SCRIPT_FILENAME /usr/share/nginx/html$fastcgi_script_name; o php não conseguirá interpretar os scripts subjacentes no path (document root).

Bora meter o pau e ver como tudo ficou bombado?

root@appunixlabs:# /etc/init.d/nginx restart

E para ver que a parada está de fato funcionando/bombando/matando a pau devemos usar qualquer coisa do php para interpretação (testes), podemos usar o phpinfo mesmo. Para isto faça o seguinte:

root@appunixlabs:# vim /usr/share/nginx/html/index.php

Dentro dele coloque o seguinte:

< ?php phpinfo(); ?>

Depois disso, para testificarmos que a parada tá rodando devemos acessar por nosso navegador http://10.0.0.1/index.php

Pronto!

Fontes:

nginx: http://nginx.net/
nginx Wiki: http://wiki.codemongers.com/Main
PHP: http://www.php.net/
MySQL: http://www.mysql.com/
CentOS: http://www.centos.org/
How2Forge: http://migre.me/5rRVS

Como instalar php apache mysql phpmyadmin no Centos 6

15/07/2011 by OwnServer

Olá pessoal, como vocês sabem somos fanáticos pelo ambiente LAMP e agora iremos colocar para vocês um how to simples porém funcional de como instalar o apache, mysql, php e phpmyadmin na plataforma CentOs 6.

Vamos começar deixando tudo atualizado e corrigido:

[root@appunixlabs ~]# yum clean all && yum update -y

Agora vamos instalar o mysql:

[root@appunixlabs ~]# yum install mysql mysql-server -y

Devemos dar pemrissões para que o mysql (serviço) carregue no momento do boot:

[root@appunixlabs ~]# chkconfig –levels 235 mysqld on

E em seguida iniciar o sistema de banco de dados:

[root@appunixlabs ~]# /etc/init.d/mysqld start

Para setarmos as senhas de mysql devemos usar o seguinte comando:

[root@appunixlabs ~]# mysql_secure_installation

NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MySQL
SERVERS IN PRODUCTION USE! PLEASE READ EACH STEP CAREFULLY!

In order to log into MySQL to secure it, we’ll need the current
password for the root user. If you’ve just installed MySQL, and
you haven’t set the root password yet, the password will be blank,
so you should just press enter here.

Enter current password for root (enter for none):
OK, successfully used password, moving on…

Setting the root password ensures that nobody can log into the MySQL
root user without the proper authorisation.

Set root password? [Y/n] Enter para confirmar que quer mudar a senha de root
New password: Coloque a nova senha de root
Re-enter new password: Confirme a nova senha de root
Password updated successfully!
Reloading privilege tables..
… Success!

By default, a MySQL installation has an anonymous user, allowing anyone
to log into MySQL without having to have a user account created for
them. This is intended only for testing, and to make the installation
go a bit smoother. You should remove them before moving into a
production environment.

Remove anonymous users? [Y/n] Pressione Enter para invalidar acessos anônimos
… Success!

Normally, root should only be allowed to connect from ‘localhost’. This
ensures that someone cannot guess at the root password from the network.

Disallow root login remotely? [Y/n] Pressione Enter para Remover o acesso remoto ao banco de dados
… Success!

By default, MySQL comes with a database named ‘test’ that anyone can
access. This is also intended only for testing, and should be removed
before moving into a production environment.

Remove test database and access to it? [Y/n] Pressione Enter para remover a base de dados de testes
– Dropping test database…
… Success!
– Removing privileges on test database…
… Success!

Reloading the privilege tables will ensure that all changes made so far
will take effect immediately.

Reload privilege tables now? [Y/n] Pressione enter para que o flushprivileges opere imediatamente e valide as mudanças
… Success!

Cleaning up…

All done! If you’ve completed all of the above steps, your MySQL
installation should now be secure.

Thanks for using MySQL!

[root@appunixlabs ~]#

Agora vamos instalar o apache com o seguinte comando:

[root@appunixlabs ~]# yum install httpd -y

Agora devemos deixar o apache com a mesma essência de serviços do mysql, operando assim que o boot for realizado:

[root@appunixlabs ~]# chkconfig –levels 235 httpd on

E para iniciarmos o bichão (apache):

[root@appunixlabs ~]# /etc/init.d/httpd start

Se quisermos acessar o server para garantir que o mesmo está operando filé em nosso sistema operacional, caso o server esteja em rede podemos acessa-lo através de seu respectivo ip. Pressupondo que o ip deste server seja 10.0.0.1, para que meu pc em rede confirme se o apache está fino podemos abrir nosso navegador e colocar o seguinte endereço: http://10.0.0.1
Uma página do apache sob CentOs será exibida mostrando que tudo está filé.

Vamos agora instalar o php

[root@appunixlabs ~]# yum install php

Devemos reiniciar o apache para garantir que a integração do interpretador esteja 100% eficaz:

[root@appunixlabs ~]# /etc/init.d/httpd restart

Aonde fica o danado do path do php em meu sistema operacional Centos???
Calma, fique tranquilo, tudo está situado em /var/www/html, e para provar que sua instalação ficou filé faça o seguinte:
Nessa pasta crie um arquivo chamado index.php, abra-o com o vim ou crie-o com echo e dentro dele coloque uma instrução, veja o passo a passo:

[root@appunixlabs ~]# echo "<?php phpinfo(); ?>" >> index.php

Pressupondo que o ip deste server seja 10.0.0.1, para que meu pc em rede confirme se o apache está fino podemos abrir nosso navegador e colocar o seguinte endereço: http://10.0.0.1/index.php

Deverão ser exibidas todas as extensões e variáveis globais predefinidas na instalação nesta página acessada.

Agora precisamos fazer com que o mysql esteja integrado com o php, para isso iremos rodar o seguinte comando:

[root@appunixlabs ~]# yum install php-mysql php-gd php-imap php-ldap php-mbstring php-odbc php-pear php-xml php-xmlrpc -y

E para garantir que tudo está filé e com integração perfeita com nosso container vamos rodar o seguinte:

[root@appunixlabs ~]# /etc/init.d/httpd restart

Precisamos fechar com chave de ouro agora no ponto de instalação fo phpmyadmin.
Para isto devemos fazer o seguinte-> Instalar o repositório RPMForge que é simplesmente punk e em seguida instalar os pacotes vindouros dele. Vamos por a mão na massa?

[root@appunixlabs ~]# rpm –import http://dag.wieers.com/rpm/packages/RPM-GPG-KEY.dag.txt

Se seu sistema for 64 bits rode:

[root@appunixlabs ~]# yum install http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm

Se seu sistema for 32 bits rode:

[root@appunixlabs ~]# yum install http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.2-2.el6.rf.i686.rpm

Agora vamos instalar o phpmyadmin:

[root@appunixlabs ~]# yum install phpmyadmin -y

Precisamos agora criar aliases para que o phpmyadmin seja acessível sem qualquer transtorno junto ao apache, para isto devemos mudar o seguinte conf-> /etc/httpd/conf.d/phpmyadmin.conf e devemos mudar o seguinte, comentar as linhas abaixo (caso não estejam comentadas):

1
2
3
4
5
#&lt;Directory "/usr/share/phpmyadmin"&gt;
#  Order Deny,Allow
#  Deny from all
#  Allow from 127.0.0.1
#&lt;/Directory&gt;


E garantir que os aliases estejam conforme os abaixo dessa linha:

Alias /phpmyadmin /usr/share/phpmyadmin
Alias /phpMyAdmin /usr/share/phpmyadmin
Alias /mysqladmin /usr/share/phpmyadmin

Feito isso devemos garantir que nosso phpmyadmin faça validação por HTTP e não por meio de cookies, devemos editar o seguinte conf /usr/share/phpmyadmin/config.inc.php e mudar a seguinte linha:

/* Authentication type */
$cfg[‘Servers’][$i][‘auth_type’] = ‘http’;

Em http fica cookie, troque cookie por http para evitar dor de cabeça.

Depois de salvar o arquivo faça com que tudo esteja validado reiniciando o apache:

[root@appunixlabs ~]# /etc/init.d/httpd restart

Pressupondo que o ip deste server seja 10.0.0.1, para que meu pc em rede confirme se o apache está fino podemos abrir nosso navegador e colocar o seguinte endereço: http://10.0.0.1/phpmyadmin

Tudo ok?

Abraços e bons estudos.

Fontes:

Centos: http://centos.org/
Apache: http://apache.org
Mysql: http://mysql.com/
PhpMyadmin: http://www.phpmyadmin.net/home_page/index.php
PHP: http://www.php.net/
Linux: http://en.wikipedia.org/wiki/Linux
RPMForge: http://rpmrepo.net/RPMforge
How to forge: http://www.howtoforge.com/installing-apache2-with-php5-and-mysql-support-on-centos-6.0-lamp

Como fazer QoS de banda (controle de banda) no Ubuntu Server, Debian, Fedora, Centos, RedHat e etc

14/07/2011 by OwnServer

Vamos perceber o seguinte.
Esse how to serve para TODAS as distribuições que rodam como um gateway de internet, sendo somente um caso de particularidade a questão de paths de configurações, como por exemplo, para instalar o CBQ no ubuntu basta usar apt-get install shaper -y.
Isto instalará ele e basta você localizar o path aonde o script shaper está (/etc/init.d/shaper) e seus respectivos confs (/etc/shaper).
No caso das outras distribuições (red hat based -> Centos, Fedora e Red Hat) podemos ver que seu path fica em /etc/sysconfig/cbq. No caso de red hat já existe um arquivo de exemplo que serve para mostrar como as coisas são configuradas no padrão, seu nome é cbq-0000.example e existe outro mas é um caso de utilização do próprio CBQ, o avpkt.
Neste caso iremos criar tudo na mão.
Antes de por a mão na massa temos de entender algumas regras PRIMÁRIAS do CBQ.
Abaixo seguem as mesmas:

O nome dos arquivos de download

cbq-0002-download.in

Todos os arquivos de download devem obedecer a algumas regras na hora de serem nomeados. A primeira delas é que todos os arquivos de download devem começar com cbq-

cbq-0002-download.in

A numeração sempre deve começar a partir do 0002;

cbq-0002-download.in

Todos os arquivos devem terminar com .in

cbq-0002-download.in

O conteúdo dos arquivos de download

DEVICE=eth1,10Mbit,1Mbit
RATE=64Kbit
WEIGHT=6Kbit
PRIO=5
RULE=10.0.0.2
BOUNDED=yes
ISOLATED=yes

DEVICE=eth1,10Mbit,1Mbit – Esta linha contém a interface que sai para os clientes da rede.
RATE=64Kbit – Quantidade de banda destinada ao cliente. Aqui coloca-se qualquer valor que se deseje separar para o IP do cliente.
WEIGHT=6Kbit – Taxa máxima de download que o cliente pode alcançar (com pequenas variações para mais ou para menos).
PRIO=5 – Prioridade com que o IP do cliente deve ser vigiado. O normal é deixar 5.
RULE=10.0.0.2 – IP do cliente a ser vigiado.
BOUNDED=yes – Se setado para yes o usuário estará limitado mesmo que o link esteja com folga.
ISOLATED=yes – Se setado para yes indica que o cliente não poderá emprestar banda pra ninguem.

Arquivos de upload
O nome dos arquivos de upload

cbq-0002-upload.out

Todos os arquivos de upload devem obedecer a algumas regras na hora de serem nomeados. A primeira delas é que todos os arquivos de upload devem começar com cbq-

cbq-0002-upload.out

A numeração sempre deve começar a partir do 0002;

cbq-0002-upload.out

Todos os arquivos devem terminar com .out

cbq-0002-upload.out

O conteúdo dos arquivos de upload

DEVICE=eth1,10Mbit,1Mbit
RATE=64Kbit
WEIGHT=6Kbit
PRIO=5
RULE=10.0.0.2,
BOUNDED=yes
ISOLATED=yes

DEVICE=eth1,10Mbit,1Mbit – Esta linha contém a interface que sai para os clientes da rede.
RATE=64Kbit – Quantidade de banda destinada ao cliente. Aqui coloca-se qualquer valor que se deseje separar para o IP do cliente.
WEIGHT=6Kbit – Taxa máxima de download que o cliente pode alcançar (com pequenas variações para mais ou para menos).
PRIO=5 – Prioridade com que o IP do cliente deve ser vigiado. O normal é deixar 5.
RULE=10.0.0.2, – IP do cliente a ser vigiado. Observe que no arquivo de upload, o IP termina com uma vírgula (,).
BOUNDED=yes – Se setado para yes o usuário estará limitado mesmo que o link esteja com folga.
ISOLATED=yes – Se setado para yes indica que o cliente não poderá emprestar banda pra ninguem.

Iniciando o CBQ

Depois de criadas todas as regras, é preciso compilá-las, com o comando (isto em fedora, redhat e centos):

root@appunixlabs~# cbq compile

No caso do Debian, Ubuntu, Mint e similares:

root@appunixlabs~# /etc/init.d/shaper compile

Basta, depois da compilação, iniciar o CBQ com o comando (isto em fedora, redhat e centos):

root@appunixlabs~# cbq start

No caso do Debian, Ubuntu, Mint e similares:

root@appunixlabs~# /etc/init.d/shaper start

Ou se desejar pará-lo (isto em fedora, redhat e centos):

root@appunixlabs~# cbq stop

No caso do Debian, Ubuntu, Mint e similares:

root@appunixlabs~# /etc/init.d/shaper stop

CBQ na inicialização

Adicione o comando cbq start ao rc.local para que carregue sozinho no ato do boot
(isto em fedora, redhat e centos):

root@appunixlabs~# echo "cbq start" >> /etc/rc.local

No caso do Debian, Ubuntu, Mint e similares:

root@appunixlabs~# echo "/etc/init.d/shaper start" >> /etc/rc.local

Fontes:

http://www.ubuntu.com/ubuntu (ubuntu)
http://www.debian.org/ (debian)
http://centos.org/ (centos)
http://www.projetofedora.org/ (fedora)
http://sourceforge.net/projects/cbqinit/ (cbq)
http://migre.me/5gcMr (cbq sob fedora)

How to sobre como usar o Subversion (usuário)

30/06/2011 by OwnServer

Prefácio

Lancei este tutorial sobre o Subversion, originalmente, no dia 30 de maio de 2005 ainda pelo PATUX – Projeto de Aprendizado Tecnológico Universitário, na Universidade de Brasília (UnB), a partir de traduções e adaptações do manual oficial do mesmo (http://svnbook.red-bean.com). Tinha como objetivo explicar o funcionamento deste sistema de versionamento (com documentação deficitária, em português, à época), e ensinar os membros do projeto a acessar os repositórios e contribuir para o desenvolvimento de software livre.Desde então, muita coisa mudou: o projeto terminou, o Subversion (que na período estava na versão 1.0.8 e era visto com certa desconfiança em relação ao já estabelecido CVS) já chegou à versão 1.5.4, vários novos front-ends foram lançados, suporte às mais populares IDEs (Eclipse, Visual Studio, entre outras) foi adicionado e, não menos importante (pelo menos para mim :P), pude alcançar um sonho particular: trabalhar e liderar conjuntamente uma empresa que verdadeiramente representa e trabalha em prol do software livre, a PWSys – Soluções em Tecnologia.

Assim sendo, creio ser de grande valia o relançamento deste documento, revisado e generalizado para utilização em cenários menos específicos que os que imaginei inicialmente. Reforça, ainda, a posição de comprometimento da PWSys com relação ao software livre e sua comunidade: outros documentos como este serão lançados, estando dispostos para auxiliar a propagação da cultura open source no Brasil.

Dito isso, sigam com o prefácio original deste tutorial.

Este tutorial visa dar uma introdução rápida sobre como utilizar o sistema de controle de versões Subversion. Este tutorial consistirá basicamente de quatro capítulos (clique nos links para ir diretamente):

  1. O que é o Subversion?
  2. Conceitos básicos de versionamento
  3. Comandos do Subversion
  4. Front-ends
Espero que com o que for explicado aqui o leitor possa utilizar de pronto e sem maiores problemas qualquer repositório Subversion. Esta é uma leitura altamente recomendada para os iniciantes em sistemas de versionamento, porém se quiser obter mais informações consulte o site oficial do Subversion (http://subversion.tigris.org) e o manual oficial (http://svnbook.red-bean.com), que contém muito mais detalhes do que este documento. Quaisquer dúvidas ou sugestões busque diretamente o autor, em seu e-mail (
<!–
var prefix = ‘ma’ + ‘il’ + ‘to’;
var path = ‘hr’ + ‘ef’ + ‘=’;
var addy72051 = ‘fbscarel’ + ‘@’;
addy72051 = addy72051 + ‘pwsys’ + ‘.’ + ‘com’ + ‘.’ + ‘br’;
document.write( ‘<a ‘ + path + ‘\” + prefix + ‘:’ + addy72051 + ‘\’>’ );
document.write( addy72051 );
document.write( ‘<\/a>’ );
//–>\n fbscarel@pwsys.com.br
<!–
document.write( ‘<span style=\’display: none;\’>’ );
//–>
). Boa leitura!Felipe Scarel, 10 de dezembro de 2008.

Licença

Copyright (c)  2008  Felipe Brant Scarel e PWSys – Soluções em Tecnologia
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license can be read at http://www.gnu.org/copyleft/fdl.html

Histórico de Revisões

Versão Data Autor Comentários
1.1 2008-12-10 11:25:26 Felipe Scarel Novo prefácio, Reescrita do Cap. 4
1.0 2005-05-30 01:30:04 Felipe Scarel Versão inicial do documento

O que é o Subversion?

O Subversion é um sistema de controle de versões livre, ou opensource. Com “sistema de controle de versões” queremos dizer que ele é capaz de gerenciar arquivos e diretórios ao longo do tempo. Basicamente, os arquivos são guardados em um repositório central e são servidos aos clientes. Muito embora isto se assemelhe a um servidor de arquivos, a diferença fundamental do Subversion é que ele guarda todas as modificações feitas nos arquivos e diretórios ao longo do tempo. Isso nos permite recuperar versões antigas dos dados ou simplesmente verificar o histórico destes. Por este motivo, é comum pensar nos sistemas de versionamento como “máquinas do tempo”. Para compreender melhor o Subversion é interessante que conheçamos um pouco da sua história:

No mundo do software livre, desde o início fez-se necessária uma ferramenta que pudesse controlar o aparente “caos” com que os programas são desenvolvidos. Para que todos pudessem desenvolver simultaneamente e sem prejuízo à organização foram criadas ferramentas de versionamento livres, sendo a mais bem-sucedida delas o Concurrent Versioning System (CVS), que logo se tornou o padrão em projetos opensource, e assim permanece até hoje. E com toda a razão, pois o fato de ser software livre, ter um design não-restritivo e bom suporte a rede permitem que vários programadores ao redor do mundo compartilhem seu código e construam softwares em conjunto. Porém, dada a sua idade, o CVS está se tornando ultrapassado, e muitos recursos modernos dos sistemas de versionamento não podem nele ser encontrados.

No início de 2000, a CollabNet (http://www.collab.net) comecou a buscar programadores para desenvolver um substituto ao CVS, que pudesse implementar o que ele apresenta de melhor mas sem copiar suas falhas mais evidentes. Eles então buscaram Karl Fogel (também um dos autores do livro do Subversion), que já vinha discutindo idéias semelhantes com seu amigo Jim Blandy. Este último inclusive já havia tido não apenas a idéia do nome “Subversion” bem como feito o layout básico de um repositório Subversion. Chamado pela CollabNet, Karl imediatamente foi trabalhar no projeto e Jim fez com que sua companhia, a conhecida Red Hat, praticamente o doasse ao projeto. Fortalecidos ainda pela contratação de Ben Collins-Sussman, eles iniciaram a codificação, e, após catorze meses, mais precisamente a 31 de Agosto de 2001, o Subversion passou a versionar seu próprio código e tornou-se uma realidade.

Muito embora os sistemas de versionamento, e por conseguinte o Subversion, sejam mais comumente usados para auxiliar programadores em seu desenvolvimento, é importate frisar que o Subversion não é limitado a ajudar programadores e pode ser utilizado para versionar qualquer tipo de dado. Para esclarecer os conceitos por trás dos sistemas de versionamento leia o próximo capítulo, que tratará precisamente deste tema. Se já estiver acostumado com estes conceitos e quiser apenas ver como o Subversion os implementa, pode seguir diretamente para o capítulo 3. Caso queira começar realmente rápido, mas provavelmente sem uma base teórica necessária, siga para o capítulo 4.

Conceitos Básicos de Versionamento

O Subversion é um sistema centralizado para compartilhar informações e dados. Ele é baseado em um repositório central, onde os dados ficam guardados sob a forma típica de uma árvore de arquivos e diretórios. Um número qualquer de clientes conectam-se ao repositório e lêem (recebendo as informações dos outros) ou escrevem (disponibilizando a informação aos demais) nestes dados. Até o momento isto não seria muito diferente de um servidor de arquivos normal, mas como foi explicado no primeiro capítulo, o Subversion tem a capacidade de guardar todas as alterações feitas aos arquivos, permitindo que elas sejam observadas, comparadas entre si, e eventualmente sobrescritas umas sobre as outras.Já sabemos o principal objetivo dos sistemas de versionamento. Porém, como faríamos para que todos pudessem trabalhar colaborativamente mas sem que ocorresse uma eventual sobrescrita, acidental, em nosso repositório? Vamos primeiramente apresentar o problema:

  • Suponhamos que dois usuários leiam as informações do repositório e iniciem a fazer modificações para posteriormente submeter suas contribuições. Se um usuário mandar suas modificações, e, logo depois, o outro também tiver a mesma idéia, o que ocorrerá é que as modificações do primeiro usuário não serão visualizadas ou aproveitadas, pois serão substituídas pelas alterações do segundo (uma vez que o padrão é visualizar a versão mais recente).

Para este problema temos duas soluções que são largamente utilizadas pelos sistemas de versionamento: a “Lock-Modify-Unlock” (Trancar-Modificar-Destrancar) e a “Copy-Modify-Merge” (Copiar-Modificar-Unir). Vamos apresentar separadamente cada uma delas:

  • “Lock-Modify-Unlock”:

Muitos sistemas de versionamento utilizam esta solução, que consiste basicamente em um sistema  parecido com o aluguel de livros em uma biblioteca: um usuário tranca o arquivo para edição, e enquanto ele faz suas modificações os demais não podem acessar o arquivo para escrita; se tentarem fazê-lo, o servidor irá negar a requisição. Logo após o primeiro usuário encerrar sua edição, ele irá destrancar o arquivo, e agora sim os demais poderão acessá-lo. Os problemas desta solução logo aparecem, pois ela é muito restritiva: se o primeiro usuário, por exemplo, sair de férias e esquecer o arquivo trancado, os demais terão que esperar até que ele volte ou contatar um administrador do sistema, o que não é desejável. Outro fator: suponhamos que dois usuário queiram editar o mesmo arquivo; isto não será um problema se um deles quiser editar o começo do arquivo e o outro quiser editar o final deste, e neste caso a solução tornaria o processo burocrático. Finalmente, esta solução cria um falso senso de segurança, pois se dois usuários trancarem arquivos diferentes, porém dependentes entre si, eles poderão modificá-los de forma a torná-los incompatíveis. Neste caso o sistema não teve poder para impedir que tal fato prejudicial ocorresse.

  • “Copy-Modify-Merge”:
O Subversion, CVS, e outros sistemas de versionamento preferem utilizar esta solução como uma alternativa ao trancamento dos arquivos. Neste modelo, cada usuário contata o repositório e copia para si a chamada “working copy”, que é uma cópia fiel da estrutura de arquivos e diretórios do servidor. Esses usuários trabalham em suas cópias particulares em paralelo, e finalmente suas modificações são unidas em uma versão final. Na maioria das vezes o repositório cuida do trabalho de fazer a união ocorrer corretamente, mas em última instância um ser humano deve cuidar desse processo. Na prática, suponhamos que dois usuários obtivessem working copies para si e comecassem a editá-las. Se um deles submeter suas modificações primeiro, quando o outro tentar mandar suas alterações o repositório lhe retornará um erro de “out-of-date” (arquivo antigo). Neste caso, o usuário receberá uma cópia do arquivo novo e deverá comparar esta nova versão com a sua, alterada localmente. Há uma boa chance de que as modificações não sejam conflitantes, e ele então poderá unir suas modificações com as de seu colaborador e submeter uma nova versão, com ambas as contribuições. Mas e se as alterações forem conflitantes? Como o próprio nome indica, nesse caso temos um “conflict” (conflito), e este deverá ser resolvido pelo usuário (uma vez que o programa não é capaz de tomar as decisões inteligentemente). Após resolver o conflito preexistente, possivelmente após uma conversa com o outro usuário, ele poderá então mandar a versão final e funcional.

O modelo utilizado pelo Subversion pode parecer caótico, mas quando vamos observá-lo mais de perto veremos que ele funciona de forma transparente; conflitos são infrequentes, e, quando ocorrem, são resolvidos rapidamente. Isso depende, contudo, de uma comunidade comunicativa e responsiva.

Comandos do Subversion

Vamos ver agora o Subversion em ação. Utilizaremos nos exemplos o cliente de linha de comando do Subversion, “svn”. No quarto capítulo apresentarei ainda alguns clientes gráficos do Subversion para poupar aqueles de vocês que não apreciam a interface de texto.

Primeiramente, suponhamos que iremos acessar um repositório exemplo. Vamos cuidar então da primeira parte, que será obter nossa working copy. Talvez fosse uma boa idéia ver a estrutura de diretórios do repositório exemplo na web, através de um visualizador como o WebSVN; digamos que a estrutura dos diretórios no servidor fosse a seguinte:

svn/
.
. exemplo/
. tags/
. branches/
. trunk/
. README
.
. outros/
. x/
. y/
. z/

Vamos começar então com o comando mais importante de todos – como obter ajuda:

[shell]$ svn help

O comando acima mostraria todos os complementos possíveis ao “svn”, e poderíamos então descobrir qual comando é o mais apropriado para o nosso problema. Supondo agora que gostaríamos de obter uma working copy do repositório exemplo, digitaríamos então o seguinte comando:

[shell]$ svn checkout http://www.foo.bar/svn/exemplo
A  exemplo
A  exemplo/tags
A  exemplo/branches
A  exemplo/trunk
A  exemplo/trunk/README
Checked out revision 1.

Este comando faria o checkout, ou cópia, da pasta “exemplo”, com todo o seu conteúdo, para o diretório atual. Isto quer dizer que, com este comando, obteríamos uma working copy para edição local, possibilitando-nos que trabalhássemos nela de pronto.

Podemos observar naquela última linha “Checked out revision 1″; vejamos o que ela exatamente quer nos dizer: ela nos informa que acabamos de fazer o checkout (ou cópia) dos arquivos do servidor pertencentes à revisão 1. Quando dizemos “revisão 1″, estamos nos referindo ao estado exato do repositório quando este se encontrava na referida revisão 1. Após alguém mandar alterações ao repositório, este passará à revisão 2, que será a mais recente (também conhecida como HEAD). Mas a revisão 1 ainda estará lá, e podemos vê-la ou recuperá-la com os comandos nativos do subversion, normalmente adicionando o switch “-r” ou “–revision”.

Podemos nos referir às revisões de três formas: a mais comum é através do número, que é único e crescente (como em “revision 1″); outra forma é através de palavras-chave que o Subversion nos fornece, como por exemplo HEAD (que se refere à revisão mais recente no repositório); finalmente, podemos nos utilizar ainda de datas em formatos predefinidos.

Expliquemos ainda a estrutura de diretórios dividida em trunk/, branches/ e tags/, largamente utilizada como padrão em repositórios: o diretório trunk/ contém a linha principal de desenvolvimento do projeto, e é nela que boa parte do código é desenvolvido. Pode ser necessário, no entanto, que se desenvolva uma nova capacidade ou característica de um programa, por exemplo. Tal desenvolvimento potencialmente tornaria o código da linha trunk/ instável, e, para evitar esse fato criaríamos um branch do projeto, focado unicamente em desenvolver essa característica específica que seria posteriormente portada de volta à árvore trunk/. Esta é superficialmente a função do diretório branches/.

É também perfeitamente possível que um programa, documento, etc, chegue em um nível de estabilidade tal que poderia ser liberado ao público e no qual não seria desejável nenhuma alteração. Essa é a função do diretório tags/, no qual residem as denominadas versões “estáveis” do projeto em questão.

Retornando aos comandos do Subversion, suponhamos agora que você deixou sua working copy parada por uns tempos e agora resolveu voltar a trabalhar nela. É possível, na verdade provável, que o estado do repositório tenha sido alterado desde sua última conexão. Para trabalhar em cima das versões mais recentes, é necessário que baixemos as modificações, e o faremos através do svn update:

[shell]$ svn update
U  exemplo/trunk/README
U  exemplo/trunk/novo.txt
Updated to revision 2.

Este comando deverá ser executado sob o diretório em que se encontra a working copy, obviamente. Ele irá buscar no servidor as modificações ocorridas em relação à versão local e aplicá-las de imediato.

A esta altura você deve ter notado as letras que apareceram nos últimos comando, A e U. Mas o que elas querem dizer? Vamos ver a seguir:

  • U: o arquivo foi “Updated” (atualizado) a partir do servidor
  • A: o arquivo ou diretório foi “Added” (adicionado) à sua working copy
  • D: o arquivo ou diretório foi “Deleted” (deletado) da sua working copy
  • R: o arquivo ou diretório foi “Replaced” (substituído) em sua working copy, ou seja, um elemento foi deletado e posteriormente outro com o mesmo nome foi adicionado; embora tenham o mesmo nome o repositório consegue percebê-los como arquivos diferentes
  • G: o arquivo no servidor recebeu alterações, mas sua cópia local tinha as suas modificações; ou as alterações não interceptavam ou eram idênticas às suas, então o Subversion conseguiu colocá-las em  estado de “merGed” (união) sem problemas
  • C: o arquivo recebeu alterações “Conflicting” (conflitantes) com as suas, ou seja, na mesma seção do arquivo; trataremos deste caso mais adiante no capítulo

Agora que já temos nossa working copy, podemos começar a trabalhar nela. Temos a possibilidade de fazer dois tipos de mudança: em arquivos específicos ou em diretórios (adicionando e removendo arquivos, por exemplo). No primeiro caso, não é necessário informar o Subversion com algum comando específico, pois ele será capaz de perceber quais arquivos foram mudados e submeter essas alterações ao servidor. Já no segundo caso, poderemos usar um dos quatro comandos básicos para manipulação de arquivos, explicados abaixo:

  • svn add

[shell]$ svn add novo.txt
A novo.txt

Este comando irá adicionar o arquivo “novo.txt” ao sistema de controle de versões, e ele também passará a ser versionado pelo repositório Subversion. Isto quer dizer que o arquivo existia para o seu computador mas era ignorado pelo Subversion, e, ao usar o “svn add”, você informou o Subversion que ele deve agora ser versionado. Se fosse um diretório, ele e todos os seus arquivos subjacentes seriam também adicionados. Vale lembrar que este passo não é opcional: não basta criar o arquivo, o “svn add” é fundamental.

  • svn delete

[shell]$ svn delete novo.txt
D novo.txt

Este outro comando irá agendar “novo.txt” para deleção do repositório. Se este fosse um arquivo ou link simbólico, ele seria imediatamente deletado da sua working copy; se fosse um diretório, seria deletado apenas após mandarmos as alterações ao servidor. É importante frisar que, após mandarmos as mudanças de volta ao repositório, o arquivo será deletado apenas da revisão mais recente, mas ainda estará presente nas revisões anteriores.

  • svn copy

[shell]$ svn copy novo.txt velho.txt
A velho.txt

O “svn copy” acima irá copiar o arquivo “novo.txt”, juntamente com seu histórico, para um arquivo denominado “velho.txt”, que será imediatamente agendade para adição no repositório. O histórico do arquivo criado irá indicar que ele é proveniente de um outro.

  • svn move

[shell]$ svn move novo.txt velho.txt
A velho.txt
D novo.txt

Como pode ser visto acima, o “svn move” irá apenas fazer o papel de “svn copy” e “svn delete” em um só comando; ele irá copiar o arquivo com um outro nome e depois irá deletar o original, o que seria basicamente o equivalente a renomear um arquivo qualquer.

Agora que já editamos o que fosse necessário ou desejável, seria interessante verificar o que foi modificado antes de mandar nossas alterações ao repositório, criando uma nova revisão. Podemos fazê-lo através do svn status (certamente o comando que você deve, espera-se, mais utilizar no Subversion):

[shell]$ svn status
M      bar.c
?      foo.o
!      qq_dir
I      .screenrc
A  +   moved_dir
M  +   moved_dir/README
D      outros/teste.c
A      outros/calc/soma.h
C      outros/calc/divide.c
R      xyz.c
S  outros/game

Temos acima um possível exemplo de saída do comando “svn status”, que nos ajudará a explicar os status mais importantes a serem compreendidos. Na primeira coluna, temos:

  • A: o arquivo/diretório foi agendado para adição no repositório
  • C: o arquivo está em estado de conflito e será necessário resolvê-lo antes de mandar as alterações ao servidor
  • D: o arquivo/diretório foi agendado para deleção no repositório
  • M: o conteúdo do arquivo foi modificado
  • R: o arquivo foi agendado para substituição no repositório, com o mesmo nome de um que foi deletado
  • ?: o arquivo em questão não está sob controle de versão (possivelmente foi criado e não foi utilizado o “svn add”)
  • !: o arquivo não está presente por algum motivo, possivelmente tendo sido deletado sem o uso de um comando Subversion
  • I: o arquivo foi configurado para ser ignorado pelo sistema de controle de versões;

Na coluna seguinte poderemos ver um “+” ou não, indicando que um arquivo foi agendado para adição no repositório com a preservação de seu histórico. Isso provavelmente nos dirá que ele é proveniente de uma cópia com o “svn copy” (A+), ou, além de ter sido copiado também foi modificado localmente (M+). A última coluna nos dirá se um arquivo ou diretório foi deslocado do caminho do restante de sua working copy, com o comando “svn switch”, para um branch ou tag (explicados mais à frente). Para a referência completa dos possíveis outputs do “svn status” consulte o manual oficial do Subversion.

Adicionando o switch “-u” ou “–show-updates” ao “svn status”, juntamente com a opção “-v” ou “–verbose” (para maior detalhamento), ele irá contatar o servidor e comparar suas modificações com as revisões que lá se encontram, e irá informar sobre arquivos antigos (out-of-date):

[shell]$ svn status –show-updates –verbose
M      *        44        23    john      README
M               44        20    david     bar.c
*        44        35    susan     outros/teste.c
Status against revision:   46

Os asteriscos acima nos indicam que caso fosse utilizado o “svn update” neste ponto os arquivos “README” e “teste.c” receberiam modificações. Isto quer dizer que nossa revisão local está desatualizada e devemos fazer um update para receber as modificações nestes arquivos e conferir se estas conflitam com a versão local.

Digamos agora que queremos saber exatamente quais modificações fizemos aos arquivos antes de mandá-las ao servidor; esta seria uma boa hora para usar o svn diff, que mostrará as diferenças entre a nossa versão modificada e a versão obtida inicialmente (que fica no diretório oculto .svn):

[shell]$ svn diff
Index: teste.c
===================================================================
— teste.c (revision 3)
+++ teste.c (working copy)
@@ -1,7 +1,12 @@
+#include
+#include
+#include
+
+#include

int main(void) {
–  printf(“Ola mundo\n”);
+  printf(“Ola de novo mundo\n”);
return 0;
}

As modificações são mostradas em formato diff unificado, sendo as linhas adicionadas mostradas com um “+” antes e as deletadas mostradas com um “-”. É interessante notar que podemos facilmente produzir um patch (arquivo incluido apenas as modificações em um arquivo) com o auxílio do svn diff, como no exemplo abaixo:

[shell]$ svn diff > patchfile

Suponhamos então que você descobrisse que as suas alterações ao “teste.c” acima foram feitas por engano, e que portanto você gostaria de retornar este arquivo ao seu estado original; é um bom momento para utilizar o svn revert:

$ svn revert teste.c
Reverted ‘teste.c’

Isto retornará nosso arquivo “teste.c” ao seu estado original, quando fizemos nosso último checkout a partir do repositório. É um processo semelhante ao utilizado para recuperar eventuais modificações mandadas ao servidor mas que foram desastrosas.

Neste último caso, bastaria dar um checkout em uma revisão anterior e funcional (usando o switch “–revision”), e posteriormente mandar esta revisão correta ao servidor novamente, se tornando HEAD.

Vale lembrar ainda que estes trás últimos comandos, muito embora lidem diretamente com os arquivos antigos, dispensam uma conexão com a rede, pois o Subversion inteligentemente mantém uma cópia imodificada dos arquivo em uma pasta oculta “.svn”, e depois apenas compara o conteúdo desta pasta com as modificações feitas pelo usuário.

Já estamos praticamente finalizados com nossa tarefa diária: sabemos adicionar e deletar arquivos, verificar as modificações feitas, conferir se estas estão desatualizadas e resolver conflitos simples, processo automatizado pelo Subversion. Mas ainda resta uma dúvida: e se nossas modificações não resultarem em um conflito simples, no qual nossa alteração intercepta diretamente a de um colaborador? Vejamos a saída de um svn update que causará esse problema:

[shell]$ svn update
U  INSTALL
G  README
C  teste.c
Updated to revision 46.

As letras U e G caem naqueles casos estudados anteriormente: no primeiro foi feito um update simples e no segundo o Subversion conseguiu unir as modificações locais e remotas sem maiores problemas. Já a terceira ocorrência poderá nos causar um problema, pois indica um conflito (C). Neste caso surgirão três arquivos no diretório de trabalho: [ARQUIVO].mine (com as alterações locais), [ARQUIVO].r[OLD] (arquivo imodificado desde o último update) e [ARQUIVO].r[NEW] (o arquivo proveniente do update, diretamente do repositório). Serão ainda colocados marcadores de conflito no arquivo original, a fim de auxiliar o processo de análise. Poderemos resolver o conflito de três formas:

  • Unir os arquivos manualmente:

Pode parecer ameaçador, mas fazer a união dos arquivos é na verdade realmente simples: analisar-se-á as alterações feitas remotamente e estas serão comparadas às locais. O usuário deverá decidir qual delas é a melhor, ou então poderá juntar ambas as soluções. De qualquer maneira, é imprescindível que haja uma boa comunicação entre os colaboradores, pois seria conveniente que houvesse uma discussão entre eles para decidir o melhor caminho.

  • Escolher uma das opções:

Pode-se ainda optar por simplesmente copiar uma das soluções inteiramente, ou a local ou a remota. Nesse caso, bastaria um “cp” simples dos sistemas UNIX-like para resolver o conflito.

  • Descartar as edições locais:

Finalmente, é também possível perceber que as alterações feitas localmente não deveriam ser mandadas ao repositório. Neste último caso, bastaria um “svn revert” para encerrar o conflito e retornar os arquivos aos seus estados originais.

Uma vez resolvidos todos os conflitos, devemos informar o Subversion, e o faremos com o comando svn resolved:

[shell]$ svn resolved teste.c

Com este comando os arquivos extras que haviam sido criados serão excluídos e a condição de conflito desaparecerá. Agora sim poderemos mandar nossas modificações ao repositório (finalmente!), e o faremos com o comando svn commit:

[shell]$ svn commit -m “Algumas modificacoes simples no arquivo teste.c”
Sending        teste.c
Transmitting file data .
Committed revision 47.

O comando acima submeterá nossas modificações locais ao repositório, e a mensagem passada através do switch “–message” ou “-m” será a mensagem de log do commit. É importantíssimo que essa mensagem descreva precisamente o que foi modificado, assim ficará muito mais fácil recuperar o repositório após um engano, além de ajudar os usuário a utilizar o sistema com mais eficiência. Essa mensagem pode ser ainda passada através de um arquivo, com o switch “–file”.

Existem ainda muitos outros comandos que este tutorial não cobriu, afinal o seu foco é de que seja uma fonte rápida para consulta e aprendizado. Dentre estes encontram-se comandos de pesquisa e administrativos. É altamente recomendada a leitura, complementar, do manual oficial do Subversion.

Front-ends

Desde a versão original deste documento, o número de front-ends disponíveis para o Subversion aumentou drasticamente, exigindo total reformulação desta seção. Aos programas descritos originalmente (RapidSVN, WebSVN e TortoiseSVN), juntaram-se vários outros dignos de nota e de usos variados, e que tornam esse sistema de controle de versão ainda mais interessante de ser utilizado. De clientes stand-alone até aqueles integrados ao desktop, passando por aplicações para browsing via web ou IDE, o número de opções para acessar e operar repositórios SVN é tanto que seria até injusto eleger alguns poucos para figurar neste tutorial.

Assim sendo, irei utilizar o mesmo approach da página de links do site oficial do Subversion (http://subversion.tigris.org/links.html): por categorias, cada aplicação e um link para sua página será apresentado, bem como uma breve descrição do programa. Sem mais delongas, vamos à lista:

  • Clientes Stand-Alone
  1. Cornerstone: cliente gráfico Subversion para Mac OS X. Não é open source, mas possui versão trial gratuita disponível
  2. eSvn: cliente gráfico multiplataforma baseado em QT para o Subversion
  3. FSVS: rápido cliente de linha de comando para o Subversion centrado em implantação de software
  4. KDESvn: cliente Subeversion para o KDE
  5. QSvn: cliente gráfico multiplataforma para o Subversion
  6. RapidSVN: cliente gráfico multiplataforma para o Subversion
  7. RSVN: script Python que permite múltiplas operações de repositório em uma única transação atômica
  8. SmartSVN: cliente gráfico multiplataforma para o Subversion. Não é open source, mas está disponível em versões gratuita e comercial
  9. Subcommander: cliente gráfico multiplataforma para o Subversion, inclui ferramenta para merge textual
  10. SvnX: cliente gráfico multiplataforma para Mac OS X Panther
  11. Syncro SVN Client: cliente gráfico multiplataforma para o Subversion. Não é open source, mas possui versão trial disponível para Mac OS X, Windows e Linux
  12. WorkBench: ambiente de desenvolvimento multiplataforma utilizando Subversion, escrito em Python
  13. Versions: cliente gráfico Subversion para Mac OS X. Não é open source; requer licença comercial
  14. ZigVersion: interface Subversion para Mac OS X. Interface voltada a workflows típicos de programadores. Não é open source
  • Clientes integrados ao Desktop
  1. Cascade: driver de sistema de arquivos multiplataforma para o Subversion, tanto gráfico quanto em linha de comando. Também provê outras funcionalidades de alto nível. Não é open source; gratuito para uso pessoal
  2. KSvn: cliente Subversion para o KDE; um plugin para o Konqueror
  3. SCPlugin: integração Subversion para o Finder do Mac OS X
  4. TortoiseSVN: um cliente Subversion, implementado como extensão do shell do Windows
  • Plugins para IDEs (vale lembrar que muitas IDEs suportam o Subversion nativamente ou por plugins inclusos; esta seção lista os plugins não-inclusos com as IDEs)
  1. Aigenta Unified SCC: plugin Subversion/CVS para programas compatíveis com MSSCCI, incluindo o Microsoft Visual Studio e outros. Não é open source, mas possui versão trial gratuita disponível
  2. AnkhSVN: integração Subversion para o Microsoft Visual Studio
  3. CW Subversion: plugin VCS para o Metrowerks CodeWarrior
  4. Subclipse: plugin Subversion para o Eclipse
  5. Subversive: plugin Subversion para o Eclipse
  6. SVN SCC Proxy: plugin SCC para SVN. Este não é um projeto open source
  7. VisualSVN: integração Subversion para o Visual Studio .NET 2003, 2005 & 2008. Este é um produto comercial de código fechado
  8. WLW-SVN: extensão Subversion para o WebLogic Workshop (8.1.3/8.1.4)
  • Outros plugins
  1. psvn.el: interface Subversion para o emacs
  2. Vcscommand.vim: plugin de integração CVS/SVN/SVK para o editor vim
  • Ferramentas de alto nível que utilizam o Subversion
  1. Trac: o Trac é um sistema web minimalista para gerenciamento de projetos e tracking de bugs e requisições. Ele provê uma interface ao sistema de controle de versões (Subversion), um Wiki integrado e funcionalidades de report
  2. Collaboa: browser de repositório e tracker de requisições, similar ao Trac
  • Browsers de repositório
  1. SVN::Web
  2. ViewVC (previamente conhecido como ViewCVS)
  3. WebSVN
  4. Insurrection: Repositório em http://svn.sinz.com/svn/Insurrection/
  5. Chora
  6. SVN::RaWeb::Light
  7. FlexySvn
  8. perl_svn
  9. mod_svn_view
  10. bsSvnBrowser
  11. sventon
  12. WebClient for SVN

Conclusão

Espero que este documento tenha sido de ajuda para o seu aprendizado, leitor, e através dele estou certo de que foi possível aprender os passos fundamentais para um dia de trabalho completo em um repositório Subversion. Agradeço a leitura e boa utilização dos repositórios!

fonte: http://pwsys.com.br/index.php?option=com_content&view=article&id=67:tutorial-usuario-subversion&catid=41:tutoriais&Itemid=66

Como alterar Timezone no CenTos/Red Hat?

30/06/2011 by OwnServer

Calma, NADA de pânico gente, se querem colocar o timezone para algo brasileiro, sigam os passos abaixo (como root):

cp -rp /usr/share/zoneinfo/Brazil/DeNoronha /etc/localtime

Se desejar outra região, mude DeNoronha para uma das citadas aqui:

Acre,

East,

West.

Lamp2: Ubuntu Server APACHE 2 Mysql 5 PHP 5 phpmyadmin

28/06/2011 by OwnServer

Um ambiente LAMP2 (apache 2 mysql 5 php 5 e phpmyadmin) é fundamental para quem desenvolve e deseja testar sua app antes de envia-la para web, sem mais, vamos aos passos:

1 – Clique em Aplicativos->Acessórios->Terminal OU CASO ESTEJA USANDO QUALQUER OUTRA VERSÃO SERVER SEM X, CTRL + ALT + F2.
2 – rode o comando:

sudo apt-get install apache2

Este comando serve para instalar o apache 2. Ressalto que usei o gestor de pacotes e habilitei o suporte a pacotes instáveis e também o repositório partner (mais abaixo posto como fazer).

Ainda no console use o comando abaixo:

sudo apt-get install php5 libapache2-mod-php5
Isto servirá para instalar o php5 e ainda integra-lo como DSO no apache (como módulo).

Já que estamos na metade do caminho o ideal seria dar um restart no apache para garantir que ele leu seu conf.
Use o comando:

sudo /etc/init.d/apache2 restart

A saída deverá ser parecida com:

* Restarting web server apache2 apache2: Could not reliably determine the server’s fully qualified domain name, using 127.0.1.1 for ServerName
… waiting apache2: Could not reliably determine the server’s fully qualified domain name, using 127.0.1.1 for ServerName
[ OK ]

Para garantir que o apache está interpretando códigos php (fazendo uso do interpretador como módulo) podemos editar um arquivo e testa-lo. use o comando abaixo:

sudo vi /var/www/index.php

Dentro deste arquivo informe:

echo 'APPUNIX é um lab de nerds!';
?>

escreva : e depois escreva wq! e pressione enter, ficando algo como :wq! , você salvará o arquivo e sairá do vi.
Feito isto acesse o arquivo para ver se a mensagem APPUNIX é um lab de nerds! aparece, caso sim, sucesso total! Do contrário releia este manual!
Este teste pode ser feito em http://localhost/index.php

Para instalar o mysql como servidor de banco de dados devemos usar o seguinte comando:
sudo apt-get install mysql-server

—
No meio desse esquema todo serão exibidas janelas que solicitarão a senha de administrador do mysql, semelhantes as imagens abaixo:

senha mysql root
senha mysql root

Outra tela:

senha root mysql 2
senha root mysql 2

Estas telas pedem para que você dê uma senha para o usuário root do mysql, escolha uma senha ao seu gosto e depois repita a mesma.

Agora iremos integrar o php + apache + mysql + phpmyadmin, para isto precisaremos usar o comando:

sudo apt-get install libapache2-mod-auth-mysql php5-mysql phpmyadmin

Neste meio tempo uma tela para escolher entre apache e lighttpd aparecerá, escolha apache. Veja:

escolha apache
escolha apache

Na primeira tela escolha OK e dê um tab para confirmar que aceita a opção.

phpmyadm
phpmyadm

A próxima tela pedirá uma senha de admin para o phpmyadmin, para isto defina algo seu. Veja a tela:

pass phpmyadm
pass phpmyadm

Costumo, após terminar uma instalação de integração como esta utilizar-me de lago, insira as seguintes linhas naquela página index.php usando sudo vim /var/www/index.php
Informe dentro dela o seguinte:

mysql_connect(‘localhost’, ‘root’, ‘suaSENHA’) or die(mysql_error());
?>

Acesse http://localhost/index.php

Se nada ocorrer tudo está 100%.

Quando terminar use o comando:
sudo /etc/init.d/apache2 restart

Isto vai fazer o apache reler todos os confs.

Para concluir precisamos levar o phpmyadmin para a pasta web afim de que possamos editar nossos bds. Para isto precisamos copiar o phpmyadmin para dentro do /var/www usando o comando:

cp -rp /usr/share/phpmyadmin /var/www

Sendo assim, para acessar somente precisamos de um http://localhost/phpmyadmin

DHCP Server Ubuntu Linux Ubuntu

27/05/2011 by OwnServer

Olá galera tudo na paz?
Hoje vou mostrar de forma simples como configurar um Servidor de DHCP no Ubuntu (diga-se Debian-like)….
DHCP é a siga Dynamic Host Configuration Protocol que é na verdade é um protocolo de serviço TCP/IP que oferece configuração dinâmica de terminais, com concessão de endereços IP de host e outros parâmetros de configuração para clientes de rede.
A comunicação do cliente com o Servidor DHCP funciona da seguinte forma, o Cliente envia um pacote em UDP em Broadcast (quer dizer que é destinado a todas a máquinas da rede) com um pedido DHCP (Configurações gerais como IP e DNS), o servidor DHCP que
primeiro capturar este pacote enviará de volta um pacote contendo as configurações, onde constará pelo menos um endereço de IP, uma máscara de rede como parâmetros opcionais Gateway, Servidor Wins, DNSs, dentre outras consigurações.
O DHCP usa um modelo cliente-servidor, no qual o servidor DHCP mantém o gerenciamento centralizado dos endereços IP usados na rede.

DHCP em Linux é mais rápido que DHCP em WIndow$?
Sim, isso não é mito… A vantagem do Linux sobre o Window$ nesta questão é que o Linux suporta o protocolo TCP/IP nativamente(via módulos de Kernel), enquanto o Window$ utiliza uma camada de compatibilidade (WInsock,que traz perda de desempenho por não estar diretamente no Kernel) para oferecer suporte a TCP/IP.
Existe também o Mito de que o DHCP Linux é mais difícil de ser configurado, Mentira…. Verão por meio desse how to que é simplista, tanto a configuração quanto manutenção desse DHCP em Linux.
Deixemos de balela e mãos a obra.

Primeiro, colocar um IP Fixo

root@appunix:~#ifconfig eth0 192.168.2.2 netmask 255.255.255.0 up

ou use esse how to e aprenda um pouco sobre configuração de interfaces de rede.

Agora é hora de instalar o pacote dhcp3-server

root@appunix:~#apt-get update

root@appunix:~#apt-get install dhcp3-server

Após o pacote intalado, pode fazer backup do arquivos de configuração do nosso DHCP(caso aconteça algum erro poderemos voltar com ele)

root@appunix:~#mv /etc/dhcp3/dhcpd.conf /etc/dhcp/dhcpd.conf.BKP

Agora vamos criar novamente o conf

root@appunix:~#vim /etc/dhcp3/dhcpd.conf

deixe o da seguinte forma (adaptando às suas necessidades)

ddns-update-style none;
default-lease-time 600;
max-lease-time 7200;
authoritative;
subnet 192.168.2.0 netmask 255.255.255.0 {
range 192.168.2.13 192.168.2.20;
option subnet-mask 255.255.255.0;
option routers 192.168.2.1;
option domain-name-servers 8.8.8.8, 8.8.4.4;
option broadcast-address 192.168.2.255;
}

Onde:
default-lease-time 600→ controla o tempo de renovação dos endereços IP em nosso caso a cada 10 minutos o servidor verifica se a estação ainda está ativa
max-lease-time 7200→ determina o tempo máximo que uma estação pode usar um determinado endereço IP, isso foi planejado em ambientes onde haja escassez de endereços IP no nosso caso cada IP fica “alugado” por no máximo 2 Horas(isso só é legal quando você tem menos IPs disponíveis do que estações e, quando todas as estações não ficam ligadas ao mesmo tempo)
authoritative→ significa que esse é o principal DHCP de sua rede
subnet 192.168.2.0 netmask 255.255.255.0→ significa faixa de faixa de IP e máscara de rede utilizada em sua rede
range 192.168.2.13 192.168.2.20→ aqui especificamos qual a largura de distribuição de IPs para no DHCP, em nosso caso o DHCP irá distribuir IPs de 192.168.2.13 até 192.168.2.20 Inclusive
option subnet-mask 255.255.255.0→ a máscra de rede para os Clintes
option routers 192.168.2.1→ aqui você define o Gateway das estações Cliente
option domain-name-servers 8.8.8.8, 8.8.4.4→ aqui são especificados os Servidores DNS usados pelo seus clientes, costumo usar os da Google (nunca tive qualquer que seja o problema em questão de nomes com esses DNSs)mas, caso tenha um servidor DNS em sua Rede(pode ser o proprio computador) pode colocar aqui o/os IPs deles
option broadcast-address 192.168.2.255→ endereço de Broadcast da Rede

Muito tranquilo…. agora caso trabalhe em uma rede onde usa-se impressoras compartilhadas em alguns hosts, é imprecindível que atribua por meio do DHCP IPs amarrados ao Mac Address (endereço físico e Único para cada placa de rede) ou seja, IPs fixos através do Servidor de DHCP.
Como fazer?
Após a Ultima linha de configuração acrescente

host doooguinha {
hardware ethernet 00:24:8c:4d:e3:7c;
fixed-address 192.168.2.15;}

onde:
host doooguinha→ é o nome o qual você queria dar a essa atribuição de IP
hardware ethernet 00:24:8c:4d:e3:7c→ é o endereço Físico (Mac Address) da minha placa de rede
fixed-address 192.168.2.15→ é o IP fixo que você quer atribuir para essa estação

* Só pra lembrar que o endereço fixo deve estar dentro da faixa de IP estabelecido na parte de range que foi explicado acima

Dica: Use servidor DHCP em uma faixa de Ips diferente daquela que você deixará para DHCP, por exemplo, da faixa de 192.168.2.1 até 192.168.2.20 (Setados na mão, em cada estação) e o restante 192.168.2.21 até 192.168.2.254 para o DHCP, Caso não o faça seu servidor DHCP poderá atribuir um endereço já utilizado por uma estação a outra
por meio do DHCP.

Após feita a configuração agora basta reiniciar o serviço e correr para o abraço

root@appunix:~#/etc/init.d/dhcp3-server restart

ou

root@appunix:~#/etc/init.d/dhcp3-server stop

root@appunix:~#/etc/init.d/dhcp3-server start

Nos clientes há várias formas de receber um Ip por DHCP
Vou mostrar todas pelo terminal

root@appunix:~#dhclient eth0

eth0 substitui-se pela interface usada por seu PC

ou

root@appunix:~#ifconfig eth0 0

onde eth0 é a interface utilizada por seu PC

Clientes WIndow$/ Mac receberam Ip normalmente de forma imperceptível.

Uma observação importante, é que ao configurar um servidor com duas placas de rede, você deve configurar o servidor DHCP para escutar apenas na placa da rede local. Em nossos testes utilizamos Ubuntu e, esta configuração está no arquivo “/etc/default/dhcp3-server”.

root@appunix:~vim /etc/default/dhcp3-server

Procure pela linha:

INTERFACES=”” e deixe de acordo com sua estrutura em nosso caso ficou INTERFACES=”eth0″ só irá escutar requisições de DHCP pela interface eth0.
É isso galera… espero ter ajudado, qualquer dúvida poste um comentário e o mais rápido possível será respondido.:D
Abraço a todos.

Mageia Linux – A primeira avaliação detalhada do Appunix no Brasil Beta 1

12/04/2011 by OwnServer

Boa noite pessoal, estava com saudades de postar coisas novas. Antes de mais nada é um ponto de muita alegria postar algo aqui que fala um pouco da minha experiência junto ao tão esperado Mageia Gnu/Linux. Há alguns dias estivemos anunciando a origem do projeto, assim como aguardando que fossem lançadas ao menos versões de testes do Mageia Linux.

Hoje temos alegria de postar nosso primeiro how to sobre como funciona o Mageia. Estamos usando a versão para arquiteturas 32 bits.

Abaixo irei descrever que hardware estou utilizando para fazer este how to:

[root@localhost ~]# lspci
00:00.0 Host bridge: Intel Corporation Core Processor DRAM Controller (rev 12)
00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 12)
00:16.0 Communication controller: Intel Corporation 5 Series/3400 Series Chipset HECI Controller (rev 06)
00:1a.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 06)
00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset High Definition Audio (rev 06)
00:1c.0 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 1 (rev 06)
00:1c.5 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 6 (rev 06)
00:1d.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 06)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev a6)
00:1f.0 ISA bridge: Intel Corporation Mobile 5 Series Chipset LPC Interface Controller (rev 06)
00:1f.2 SATA controller: Intel Corporation 5 Series/3400 Series Chipset 4 port SATA AHCI Controller (rev 06)
00:1f.3 SMBus: Intel Corporation 5 Series/3400 Series Chipset SMBus Controller (rev 06)
00:1f.6 Signal processing controller: Intel Corporation 5 Series/3400 Series Chipset Thermal Subsystem (rev 06)
02:00.0 Ethernet controller: Atheros Communications AR8151 v1.0 Gigabit Ethernet (rev c0)
09:00.0 Network controller: Broadcom Corporation BCM43225 802.11b/g/n (rev 01)
ff:00.0 Host bridge: Intel Corporation Core Processor QuickPath Architecture Generic Non-core Registers (rev 02)
ff:00.1 Host bridge: Intel Corporation Core Processor QuickPath Architecture System Address Decoder (rev 02)
ff:02.0 Host bridge: Intel Corporation Core Processor QPI Link 0 (rev 02)
ff:02.1 Host bridge: Intel Corporation Core Processor QPI Physical 0 (rev 02)
ff:02.2 Host bridge: Intel Corporation Core Processor Reserved (rev 02)
ff:02.3 Host bridge: Intel Corporation Core Processor Reserved (rev 02)
[root@localhost ~]#

 

Meu notebook foi fabricado pela Acer, a linha 7745 (inclusive já havia comentado quão amargo foi tentar achar o desktop perfeito no passado, principalmente por problemas de acpi, coisa que no Ubuntu 11.04 alpha estava corrigido, o último update ferrou com acpi novamente).

Antes de mais nada irei colocar as imagens de instalação do mesmo. Antes mesmo de comentar sobre o sistema em funcionamento (na verdade todo o ecossistema em sincronia) quero postar as imagens de instalação e falar da instalação em primeiro passo.

Tela de Instalação Mageia Linux
Tela de Instalação Mageia Linux

O sistema de boot install é muito simples e de fácil compreensão.
Para as pessoas que já têm familiaridade com instalações do Fedora, Ubuntu, Centos e afins com certeza vai se sentir em casa. Na primeira tela percebemos uma coisa, um submenu que fica no canto inferior com sugestões de linguagem padrão, tipo (layout) de teclado e parâmetros extras para o boot (normalmente gambiarras de ACPI que nada são necessárias aqui, acredite, TUDO FUNCIONA NO MAGEIA LINUX).

linguagem do sistema de instalação
linguagem do sistema de instalação

O passo inicial é escolher o idioma que o sistema terá por default. De cara colocamos o nosso, português Brasil.

idioma mageia
idioma mageia

Após, teremos de concordar e particionar o disco. Colocamos o default no espaço livre que tínhamos. Perceba que temos 2 sistemas dentro do disco, um Window$ 7 e um Mageia Linux. Um dos pontos mais interessantes na instalação é que o Mageia sugere que você instale o grub, sendo que, ao ativar o grub como gestor de boot (sistema de arranque) ele automaticamente ativa na tabela inclusa na MBR o sistema Micro$oft sem nenhum problema.

A instalação ocorreu de maneira simples e rápida (40 minutos). Escolhemos o X server operando com Gnome. Não há motivos para não usar o KDE, pois está em sua última versão mais recente/estável existente, porém estamos bem familiarizados com o Gnome. Ressaltamos que o Mageia está operando com o Gnome 2.x e não o 3.x, isto pode parecer pouco inovador para algumas pessoas, mas a versão Beta 1 do Mageia Linux NÃO está apresentando qualquer crash, principalmente em se tratando de ambiente X, por isso podemos desde já aplaudir o pessoal do core de desenvolvimento/tradução/testes do Mageia Linux.

Um ponto extra na instalação é que o sistema vai lhe perguntar se você quer ativar repositórios Extras (mídia, ftp e etc), diga NENHUM!

Assim que a instalação for concluída (cremos que não haverá qualquer problema) você vai reiniciar o PC e terá uma tela de boot muito parecida com a nossa:

Momento de Boot 1
Momento de Boot 1
Momento de Boot 2
Momento de Boot 2

Afirmo desde já que fiquei impressionado com a qualidade do gdm, assim como o desktop bem clean:

Login Mageia Linux
Login Mageia Linux
Desktop Clean Mageia
Desktop Clean Mageia

Terminada a instalação teremos duas coisas para ajustar em caráter emergencial:

1 – Rede (wireless device),

2 – Repositórios para Update.

Se o seu hardware não for detectado por completo, o máximo que vai ficar para trás é a Wireless (e olhe lá).
O suporte acpi estará 100% funcional para você (acredite).

Para resolvermos o problema de repositórios faça o seguinte -> Clique em SISTEMA -> ADMINISTRAÇÃO -> CONFIGURE SEU COMPUTADOR.

Assim que for solicitado o login de root informe para que você tenha acesso administrativo ao sistema.

No primeiro menu clique em GERENCIAR PROGRAMAS -> depois clique em CONFIGURAR MÍDIAS PARA ATUALIZAÇÃO E INSTALAÇÃO DE NOVOS PROGRAMAS.

Veja a imagem abaixo:

Escolher Mídia Mageia
Escolher Mídia Mageia

Assim que clicar a tela abaixo deverá aparecer. Remova a mídia clicando em REMOVER e em seguida clique em Adicionar, você deverá escolher a opção de adição do Conjunto de Mídias:

Selecionando Mídias no Mageia
Selecionando Mídias no Mageia

A tela de aguarde aparecerá demonstrando que você está baixando (em background) a lista com todos os repositórios disponíveis. Veja a imagem abaixo:

Preparando Lista de Repositórios
Preparando Lista de Repositórios

Assim que o sistema carregar toda a lista de repositórios marque todos, exceto marcar Mídia (CD-ROM – CORE MEDIA).

Assim que forem carregadas todas as updates, inicialmente o sistema vai lhe mostrar o que precisa ser atualizado PRA JÁ! Confirme tudo que ele mostrar. Achamos uma coisa MUITO útil para deixar o usuário informado, uma detalhada lista de changelog é disponibilizada pelo sistema de updates, veja:

o que mudou 1
o que mudou 1
o que mudou 2
o que mudou 2

Algumas pessoas curiosas podem se perguntar aonde o Mageia Linux prepara suas sources lists e as armazena em um arquivo? Fique tranquilo, ó pequeno Gafanhoto, o path está na foto abaixo:

path urpmi
path urpmi

O /etc/urpmi/mediacfg.d/ guarda as sources lists em diretórios. Lembrando que o gestor de pacotes é o poderoso URPMI 100% baseado no Mandriva (Mageia é um fork do Mandriva Linux, isso foi bem detalhado em nosso blog neste link -> Tudo Sobre Mageia). O Mageia é semelhante ao Mandriva, trabalha com o MCC (sua central de aplicativos MUITO útil) e trabalha com pacotes RPM com muito louvor.

Assim que forem sugeridas todas as atualizações, por favor atualize TUDO que estiver disponível!

lista completa de packs para update
lista completa de packs para update

Você poderá receber notificações no tocante a updates, mas não precisa ter qualquer stress, muito pelo contrário, o core de desenvolvimento do Mageia sabe o que faz. Haverão pacotes que necessitarão de serem removidos por completo pois substitutos bem melhores estarão disponíveis (melhores em segurança, desempenho e estabilidade):

sugestoes
sugestoes

Assim que forem terminados os updates, provavelmente você verá uma tela de notificação mandando que você reinicie seu PC para que sejam validadas as mudanças (isto é importante pois temos muitas coisas que realmente necessitam de reboots, desde compiladores que operam junto com processos de baixo nível como também patches do kernel), veja a notificação:

reboot
reboot

Assim que o seu pc reiniciar (seu notebook, neste caso), o próximo ponto será ativar a WIFI e otimiza-la (sim, é possível alcançar uma pequena melhoria, ensinaremos como fazer alguns truques aqui).

Em primeira fase temos que entrar no MCC novamente para facilitar o processo. Minha interface aqui utilizada é a Broadcom 43225 (bcm43xx mais famosa com esse apelido).
Clique no menu do canto superior esquerdo -> SISTEMA -> ADMINISTRAÇÃO -> CONFIGURE SEU COMPUTADOR. Em seguida, na aba GERENCIADOR DE PROGRAMAS escolha INSTALAR e REMOVER PROGRAMAS. O MCC estará pronto para uso. Você perceberá que existem 2 abas para escolhas de que tipos de pacotes queremos que sejam exibidos os status de instalação (instalados, instalar e remover programas instalados). Um normalmente está em particular ordenando a escolha de pacotes para o ambiente gráfico, escolha TODOS, assim como o segundo menu, escolha TODOS. No próximo passo digite no menu PESQUISAR o termo DKM.

Se você seguiu este passo a passo vai conseguir instalar a BROADCOM 43xx no MAGEIA LINUX (em inglês para alegrar: how to install broadcom bcm 43xx on MAGEIA LINUX).

Escolha o pacote DKMS-BROADCOM-WL, marque ele e clique em aplicar (veja a foto abaixo):

como instalar wifi mageia 1
como instalar wifi mageia 1

Após clicar em APLICAR ele vai exibir uma tela MUITO parecida com a tela abaixo, mas antemão já lhe afirmarmos para confirmar a instalação:

como instalar wifi 2
como instalar wifi 2

As imagens abaixo mostram quão prático foi o processo de instalação da Wireless junto ao Mageia com recursos da BCM43:

testando wifi broadcom mageia 1
testando wifi broadcom mageia 1
testando wifi broadcom mageia 2
testando wifi broadcom mageia 2
testando wifi broadcom mageia 3
testando wifi broadcom mageia 3

Agora vai um pequeno truque, sabemos que ipv6 está na ativa e operando a mil, porém, temos ciência também que nem todos tem rede capaz de gerenciar ipv6, ou mesmo ainda não têm necessidades de utilização deste recurso, por isso vamos otimizar as coisas por aqui. Veja que no último menu há um botão que chama-se AVANÇADO, clique nele para que você possa habilitar o menu afim de desativar o suporte da wireless broadcom bcm 43xx com ipv6:

Tricks de WIFI no MAGEIA LINUX
Tricks de WIFI no MAGEIA LINUX

Pronto!

Agora você terá uma distribuição estável e boa para uso (sabendo-se que é beta client ainda, mas a estabilidade é de dar inveja!).

Pontos extras:

 

Perceba que o suporte ao brilho do monitor, ajuste de volume e etc operam em 100% (sem gambiarras “bootais”… lol).

 

Vamos instalar o Flash Player ou é melhor deixar para outro How to?

Ahh… estou com sono, deixa para outro… Abraços -> att: little_ok and appunix group!

 

Como instalar Adobe Air e TweetDeck no Ubuntu 10.10 de maneira fácil

17/02/2011 by OwnServer

Adobe air faz os aplicativos web ficarem ricos em design, muito utilizado em cima de flex para fazer coisas impressionantes.
Gosto de usar e abusar do Adobe Air em cima do TweetDeck, este por sua vez dá show em cima do Twitter.

Bem, para instala-lo fizemos um passo-a-passo muito simples, com prints e tudo mais.
Em primeira mão devemos acessar a central de programas que está localizada no menu Aplicativos->Central de Programas do Ubuntu. A imagem a seguir demonstra bem isto:

Primeiro passo é usarmos a eficiente busca da central, veja na imagem abaixo que colocamos as duas palavras Adobe Air como sendo o termo de busca e ele exibiu a busca com o resultado que precisávamos, a caixa de busca fica no canto direito superior da central de aplicativos do Ubuntu Linux, veja o print:

Após clicarmos 2 vezes rapidamente sobre o Adobe Air localizado o Ubuntu pergunta se queremos de fato usar a fonta encontrada, devemos clicar nela, conforme imagem abaixo:

Após confirmamos a Central de Aplicativos, por medida de segurança vai solicitar a senha do usuário para que, usando método sudo dê a permissão para que a Fonte (source) da Adobe seja utilizada. Confirme a sua senha, conforme mostrado na imagem abaixo:

Após veremos que ele já está autorizado para instalar o Adobe Air no Ubuntu, devemos clicar em INSTALAR para que o sistema instale. Novamente ele vai requerer senha na autorização, mas desta vez da Instalação ao invés de origem de source. Veja;

Pronto!

Depois disto ele vai mostrar Um item no menu esquerdo chamado Progresso para que você possa acompanhar de perto o andamento do download do source (pacote .DEB) e a instalação posteriormente feita após download.

Agora nosso próximo passo será instalar o TweetDeck.

Para isto acesse o seguinte site: http://www.tweetdeck.com/desktop/

A URL acima já indica o link de instalação feito para o PC. A imagem do site não será diferente desta:

Pronto, depois de acessar o site com seu navegador (Google Chromium, Firefox, Opera ou qualquer outro) clique em Baixar Agora é Grátis, veja na imagem abaixo:

Feito isso veja o progresso do download segundo a imagem abaixo:

Feito isto vão começar os questionamentos, abrir, concordar, instalar e etc. A imagema baixo mostra como você deverá proceder:

menu_central_programas_ubuntu
escrever adobe air
usa a fonte
senha
senha
instalar
senha de novo
tweetdeck site
clicar em baixar agora e gratis
progresso de instalacao
concordar com os termos da adobe
clicar em continuar
clicar em instalar no tweetdeck dentro do adobe air
iniciando instalacao
abrir tweetdeck dentro do adobeair
tweetdeck

Pronto.
Terminando o passo-a-passo a imagem deverá ser algo semelhante a que iremos postar agora.

Depois disso o TweetDeck estará 100% funcional e disponível em seu Ubuntu.
Se estiver um pouco enrolado para localiza-lo, não se preocupe, o menu aonde ele está fica em Aplicativos->Acessórios->TweetDeck.

Enjoy!

Att: little_oak.

Navegação por posts

  • Previous
  • 1
  • 2

Pesquisa

Categorias

  • Blog
  • cPanel
  • How Tos
  • Linux
  • Mac Os
  • MySQL
  • Wordpress

#Apoiadores

Patrocinador

Registre-se e ganhe $25



© 2022 AppUnix | Built using WordPress and MxGuard