quarta-feira, 24 de agosto de 2011
sexta-feira, 12 de agosto de 2011
FreeBSD: Resolução tela modo texto
Most servers these days are headless although with some security system setups it’s still important to have physical access to the box. After a short time of using it you’ll certainly get fed up with the low resolution, here’s a way to increase your screen resolution.
Recompiling the Kernel
You’ll first need to recompile your kernel to add support for vidcontrol, you can do this as follows:
Using sysinstall ensure you have installed the following src files: base,sys
cd /usr/src/sys/amd64/conf (you may want to replace amb64 with i386)
cp GENERIC CUSTOMKERNEL
echo “options VESA” >> CUSTOMKERNEL
echo “options SC_PIXEL_MODE” >> CUSTOMKERNEL
cd /usr/src
make buildkernel KERNCONF=CUSTOMKERNEL
make installkernel KERNCONF=CUSTOMKERNEL
reboot
You’ll then need to reboot to enable the new kernel you booted. You may encounter an error suggesting you’ve run out of disk space. If this is the case you’ll probably want to “mv /boot/kernel.old /usr” and try again.
Now you’re using your new kernel you’ll be able to see a list of all available resolutions:
vidcontrol -i mode
Find a line that shows the correct resolution and make a note of the number at the start of it, I’m using 280 which is 1024x768x32
echo allscreens_flags=”MODE_280″ >> /etc/rc.conf
reboot or vidcontrol
You should now be able to enjoy many more characters on your screen, hooray!
FONTE: http://www.elfnet.org/2010/11/28/freebsd-console-terminal-resolution/
Recompiling the Kernel
You’ll first need to recompile your kernel to add support for vidcontrol, you can do this as follows:
Using sysinstall ensure you have installed the following src files: base,sys
cd /usr/src/sys/amd64/conf (you may want to replace amb64 with i386)
cp GENERIC CUSTOMKERNEL
echo “options VESA” >> CUSTOMKERNEL
echo “options SC_PIXEL_MODE” >> CUSTOMKERNEL
cd /usr/src
make buildkernel KERNCONF=CUSTOMKERNEL
make installkernel KERNCONF=CUSTOMKERNEL
reboot
You’ll then need to reboot to enable the new kernel you booted. You may encounter an error suggesting you’ve run out of disk space. If this is the case you’ll probably want to “mv /boot/kernel.old /usr” and try again.
Now you’re using your new kernel you’ll be able to see a list of all available resolutions:
vidcontrol -i mode
Find a line that shows the correct resolution and make a note of the number at the start of it, I’m using 280 which is 1024x768x32
echo allscreens_flags=”MODE_280″ >> /etc/rc.conf
reboot or vidcontrol
You should now be able to enjoy many more characters on your screen, hooray!
FONTE: http://www.elfnet.org/2010/11/28/freebsd-console-terminal-resolution/
sábado, 6 de agosto de 2011
FreeBSD: Servidor de Counter Strike
At 09:49 AM 11/7/2002, you wrote:
Para aqueles que se interessaram em montar um servidor CS no FreeBSD, acabei de faze-lo, mas não é tão direto quanto se acredita, nem ao menos é parecido com Linux.
Passos básicos:
1) Instale/atualize a árvore dos ports com o cvsup (favor consultar documentação específica)
2) Instalar a compatibilidade de Linux mais atualizada (/stand/sysinstall); Consulte documentação específica. Por volta de 24 MB.
3) Baixar o pacote http://gwforum.net/cs/ua/HL_CS_Files/halflife/hlds_l_3110_full.bin
(por volta de 118 MB)
Esse arquivo pode ser baixado de vários outros pontos na Internet. Use o Google ou similar para procurar. (esse é o SERVIDOR de Half Life propriamente dito, o "engine" que roda o MOD Counter Strike.)
Coloque-o em /usr/ports/distfiles
Neste caso esse já é o binário de Linux. É um arquivo auto-descompactável que tem a licensa de uso. Caso você concorde com ela, o arquivo irá descompactar o pacote .tar.gz completo no diretório local, que no FreeBSD TEM QUE SER o /usr/ports/distfiles .
4) Baixar o pacote de atualização para Counter Strike mais atual (1.5, hoje)
O link
http://gwforum.net/cs/ua/HL_CS_Files/cstrike/lin_server/cs_15_full.tar.gz
funciona bem, mas continua valendo o comentário anterior. Por volta de 108 MB.
Coloque-o em /usr/ports/distfiles
Esse não precisa executar. O conteúdo do arquivo vai ser usado para "patchear" o módulo de Linux hlds, e isso vai acontecer quando VC der um make.
5) tudo pronto para começar a compilar;
execute
cd /usr/ports/games/halflifeserver/
make
make install
(provavelmente este passo 5 e o seguinte são redundantes, ou, na pior das hipóteses, iguais, mas foi assim que eu fiz, e ainda não tive tempo de testar outro modo)
6) execute
cd /usr/ports/games/hlserver-cs/
make
make install
7) Edite o arquivo de configuração do servidor em
/usr/compat/linux/usr/games/hlds_l/cstrike/server.cfg
o meu está assim:
// disable autoaim
sv_aim 0
// disable clients' ability to pause the server
pausable 0
// default server name. Change to "Bob's Server", etc.
hostname "Cap_BR"
// maximum client movement speed
sv_maxspeed 320
// 20 minute timelimit
mp_timelimit 20
sv_cheats 0
rcon_password "senhadoserverCS"
mp_c4timer 30
mp_flashlight 1
mp_footsteps 1
mp_friendlyfire 1
mp_autoteambalance 1
mp_freezetime 6
mp_roundtime 3
mp_maxrounds 0
mp_mapvoteratio 0.8
mp_forcechasecam 0
Finalmente rode o servidor como USUÁRIO NÃO PRIVILEGIADO (não root, ou não pertencente ao grupo wheel). Comando:
./usr/compat/linux/usr/games/hlds_l/hlds_run -game cstrike + maxplayers 6 + exec server.cfg + map de_dust &
(tudo em uma linha só, claro. Preste atenção no "." no início do comando e o "&" no final!)
Com isso um servidor CS básico vai estar rodando em background, sem senha, para os usuários.
Lembre que assim que VC inicia o servidor ele vai:
-Baixar atualizações do site principal
-publicar-se como sendo um servidor público nas listas internacionais (portanto VC vai ser conhecido em todo o mundo) -se seu servidor estiver por trás de um firewall e/ou gateway, e com IP reservado (192.168.x.y, 10.x.y.z, 172.16.x.y) o IP do GATEWAY vai ser publicado como sendo de um servidor de jogo, e várias requisições de conexão (porta udp 27015/27005), informação (porta udp 27010) passarão a acontecer entre o servidor de jogo e a Internet, ou o GATEWAY e a internet.
Para tornar público um servidor de jogo, mantendo-o por trás do firewall/gateway, use o redirecionamento do natd ou similar da seguinte maneira:
todas as conexões chegando para o gateway para udp 27015 devem ser redirecionadas para o ip interno do servidor de jogo.
O servidor de CS é muito econômico e estimo que consuma por volta de 3 a 4% dos recursos de processamento de um Pentium 3 500 MHz com 128 MH de ram (rodando apenas isso) por jogador conectado. O único probleminha é que - pelo que eu interpretei do TOP - ele ocupa algo como 53 MB de memória ram.
Calculo uma média de 3.5 KBytes/s de saída e 2.5 Kbytes/s de entrada de dados, por cliente (jogador) conectado. Ou seja, donos de speedy 256/128, sinto muito mas não vão jogar mais do que 4 pessoas no seu server (remotamente), com boa performance. Esse consumo de banda não é estável, e varia muito durante o jogo, não atinei exatamente o porque.
Dica: Para tornar o jogo balanceado entre jogadores remotos e locais, use o pipe do ipfw para reduzir a velocidade e alterar o tempo de resposta da conexão local, e equalizar o tempo de resposta. O tempo de resposta de um cliente pode ser verificado durante o jogo apertando a tecla tab. Esse tempo de resposta é conhecido como "ping" pela comunidade CS (mas designado como "latency"), e estando entre 35 e 45 é considerado excelente. "Pings" de 100 e acima dificultam em muito o jogo para esse determinado cliente (vira presa fácil).
Clientes na rede interna deverão ter um "ping" de aproximadamente 15 a 40, com bastante flutuação.
Ainda não tenho os comandos mais avançados do servidor de CS e agradeceria se alguém os passasse para mim.
Se VC tem um servidor um pouco mais avantajado que está funcionando só como DNS ou coisas pequenas, taí uma máquina ideal para fazer uma servidor de Couter Strike.
[]s
Capriotti
FONTE: http://www.fug.com.br/historico/html/freebsd/2002-11/msg00230.html
Para aqueles que se interessaram em montar um servidor CS no FreeBSD, acabei de faze-lo, mas não é tão direto quanto se acredita, nem ao menos é parecido com Linux.
Passos básicos:
1) Instale/atualize a árvore dos ports com o cvsup (favor consultar documentação específica)
2) Instalar a compatibilidade de Linux mais atualizada (/stand/sysinstall); Consulte documentação específica. Por volta de 24 MB.
3) Baixar o pacote http://gwforum.net/cs/ua/HL_CS_Files/halflife/hlds_l_3110_full.bin
(por volta de 118 MB)
Esse arquivo pode ser baixado de vários outros pontos na Internet. Use o Google ou similar para procurar. (esse é o SERVIDOR de Half Life propriamente dito, o "engine" que roda o MOD Counter Strike.)
Coloque-o em /usr/ports/distfiles
Neste caso esse já é o binário de Linux. É um arquivo auto-descompactável que tem a licensa de uso. Caso você concorde com ela, o arquivo irá descompactar o pacote .tar.gz completo no diretório local, que no FreeBSD TEM QUE SER o /usr/ports/distfiles .
4) Baixar o pacote de atualização para Counter Strike mais atual (1.5, hoje)
O link
http://gwforum.net/cs/ua/HL_CS_Files/cstrike/lin_server/cs_15_full.tar.gz
funciona bem, mas continua valendo o comentário anterior. Por volta de 108 MB.
Coloque-o em /usr/ports/distfiles
Esse não precisa executar. O conteúdo do arquivo vai ser usado para "patchear" o módulo de Linux hlds, e isso vai acontecer quando VC der um make.
5) tudo pronto para começar a compilar;
execute
cd /usr/ports/games/halflifeserver/
make
make install
(provavelmente este passo 5 e o seguinte são redundantes, ou, na pior das hipóteses, iguais, mas foi assim que eu fiz, e ainda não tive tempo de testar outro modo)
6) execute
cd /usr/ports/games/hlserver-cs/
make
make install
7) Edite o arquivo de configuração do servidor em
/usr/compat/linux/usr/games/hlds_l/cstrike/server.cfg
o meu está assim:
// disable autoaim
sv_aim 0
// disable clients' ability to pause the server
pausable 0
// default server name. Change to "Bob's Server", etc.
hostname "Cap_BR"
// maximum client movement speed
sv_maxspeed 320
// 20 minute timelimit
mp_timelimit 20
sv_cheats 0
rcon_password "senhadoserverCS"
mp_c4timer 30
mp_flashlight 1
mp_footsteps 1
mp_friendlyfire 1
mp_autoteambalance 1
mp_freezetime 6
mp_roundtime 3
mp_maxrounds 0
mp_mapvoteratio 0.8
mp_forcechasecam 0
Finalmente rode o servidor como USUÁRIO NÃO PRIVILEGIADO (não root, ou não pertencente ao grupo wheel). Comando:
./usr/compat/linux/usr/games/hlds_l/hlds_run -game cstrike + maxplayers 6 + exec server.cfg + map de_dust &
(tudo em uma linha só, claro. Preste atenção no "." no início do comando e o "&" no final!)
Com isso um servidor CS básico vai estar rodando em background, sem senha, para os usuários.
Lembre que assim que VC inicia o servidor ele vai:
-Baixar atualizações do site principal
-publicar-se como sendo um servidor público nas listas internacionais (portanto VC vai ser conhecido em todo o mundo) -se seu servidor estiver por trás de um firewall e/ou gateway, e com IP reservado (192.168.x.y, 10.x.y.z, 172.16.x.y) o IP do GATEWAY vai ser publicado como sendo de um servidor de jogo, e várias requisições de conexão (porta udp 27015/27005), informação (porta udp 27010) passarão a acontecer entre o servidor de jogo e a Internet, ou o GATEWAY e a internet.
Para tornar público um servidor de jogo, mantendo-o por trás do firewall/gateway, use o redirecionamento do natd ou similar da seguinte maneira:
todas as conexões chegando para o gateway para udp 27015 devem ser redirecionadas para o ip interno do servidor de jogo.
O servidor de CS é muito econômico e estimo que consuma por volta de 3 a 4% dos recursos de processamento de um Pentium 3 500 MHz com 128 MH de ram (rodando apenas isso) por jogador conectado. O único probleminha é que - pelo que eu interpretei do TOP - ele ocupa algo como 53 MB de memória ram.
Calculo uma média de 3.5 KBytes/s de saída e 2.5 Kbytes/s de entrada de dados, por cliente (jogador) conectado. Ou seja, donos de speedy 256/128, sinto muito mas não vão jogar mais do que 4 pessoas no seu server (remotamente), com boa performance. Esse consumo de banda não é estável, e varia muito durante o jogo, não atinei exatamente o porque.
Dica: Para tornar o jogo balanceado entre jogadores remotos e locais, use o pipe do ipfw para reduzir a velocidade e alterar o tempo de resposta da conexão local, e equalizar o tempo de resposta. O tempo de resposta de um cliente pode ser verificado durante o jogo apertando a tecla tab. Esse tempo de resposta é conhecido como "ping" pela comunidade CS (mas designado como "latency"), e estando entre 35 e 45 é considerado excelente. "Pings" de 100 e acima dificultam em muito o jogo para esse determinado cliente (vira presa fácil).
Clientes na rede interna deverão ter um "ping" de aproximadamente 15 a 40, com bastante flutuação.
Ainda não tenho os comandos mais avançados do servidor de CS e agradeceria se alguém os passasse para mim.
Se VC tem um servidor um pouco mais avantajado que está funcionando só como DNS ou coisas pequenas, taí uma máquina ideal para fazer uma servidor de Couter Strike.
[]s
Capriotti
FONTE: http://www.fug.com.br/historico/html/freebsd/2002-11/msg00230.html
sexta-feira, 5 de agosto de 2011
ZIMBRA: Restaurar .MSG
FONTE: http://tretasonline.blogspot.com/2011/02/para-comecar.html
Tivemos um problema em um cliente que possui o pacote de colaboração do Zimbra, aconteceu que o cliente acabou perdendo os backups existentes e o zimbra havia parado de funcionar devido a algum problema no Mysql.
Enfim, tentei varias alternativas para concertar o Mysql, porém nada adiantou, depois de muita peleia acabei convertendo a maquina para uma vm em um outro servidor, e depois instalei um zimbra do zero e bastou criar as contas dos usuários...
Mas dai tu me pergunta.. e os e-mails que estavam no outro servidor?
Dai vem a pior parte, como o zimbra não levantava, eu não conseguia efetuar backup das contas, pois o script que tenho para backup faz através de HTTP, então ficou complicado...
Depois de muita busca no google e de muitas noites perdidas devido a grandes quatidades de café, consegui uma fórmula mágica...
Bem, não tão mágica, daria um pouco de trabalho, mas iria funcionar.. Vamos a ela...
O zimbra possui uma pasta onde ele armazena todos os e-mails dos usuários, "/opt/zimbra/store/0/", nesta pasta ficam os arquivos ".msg" de todos as contas, porém, cada usuário possui uma identificação, que é guardada no Mysql do zimbra (justamente o que não tava funcionando), então não tinha como saber que Id era qual usuário..
Entrando na pasta, me deparei com várias outras pastas nomeadas com a id do usuário, e dentro de cada "id" outras pastas com os ".msg" da conta...
Criei então uma conta "teste" no meu servidor zimbra com uma pasta "restaurados", e mandei converter os ".msg" para dentro dela com o seguinte comando...
/opt/zimbra/bin/zmmailbox -z -m teste@zimbrateste01.com.br addMessage /restaurados *.msg
Foi ai que percebi que era possível restaurar as mensagens que até então estavam perdidas nas contas que eu queria...
O maior trabalho foi restaurar as .msg de cada id para descobrir de quem eram aquelas mensages...
Isso demorou quase uma manha inteira, e isso que eram somente 43 contas!! (obviamente não restaurei todas as mensagens de uma conta para saber de quem eram..)
Dai parti pro shell script...
dei um "ls" na pasta com as id's ( já alteradas para os nomes dos respectivos usuários) e concatecei em um arquivo chamado "users", nesse arquivo contia então as pastas com os arquivos ".msg" e consequentemente os usuários que receberiam as mensagens...
Criei então um script que iria ler a lista de usuarios, iria criar uma pasta na conta de cada usuario da lista e também iria restaurar as mensagens de cada usuario/msg para a pasta que eu previamente havia escolhido...
O script foi rodado através de uma "screen" no linux e ficou rodando durante a noite, ao chegar na empresa pela manhã, verifiquei que todas as mensagens haviam sido restauradas..
Sendo assim, a migração das contas foi "praticamente" um sucesso, não foi "completamente" porque não foi possível salvar os "contatos, agenda, tarefas e etc..." das contas, somente as mensagens.. Mas já é alguma coisa, e o cliente ficou com as mensagens, o que sinceramente, é o mais importante né???
Deixo aqui o meu testemunho então de que é possivel restaurar os e-mails de um servidor zimbra corrompido sem ter que fazer todos os testes que eu fiz...
Ex:
Copiar pasta "store" de um servidor pro outro... (não adiantou, pois não identifica as mensagens)
Copiar pasta inteira "/opt/zimbra" - Não adiantou (ainda tive que reconfigurar o zimbra, e serviços que antes funcionavam, haviam parado!)
Se alguem estiver com o mesmo problema, só precisa entrar em contato através do meu e-mail que envio o script que faz tal tarefa...
Tivemos um problema em um cliente que possui o pacote de colaboração do Zimbra, aconteceu que o cliente acabou perdendo os backups existentes e o zimbra havia parado de funcionar devido a algum problema no Mysql.
Enfim, tentei varias alternativas para concertar o Mysql, porém nada adiantou, depois de muita peleia acabei convertendo a maquina para uma vm em um outro servidor, e depois instalei um zimbra do zero e bastou criar as contas dos usuários...
Mas dai tu me pergunta.. e os e-mails que estavam no outro servidor?
Dai vem a pior parte, como o zimbra não levantava, eu não conseguia efetuar backup das contas, pois o script que tenho para backup faz através de HTTP, então ficou complicado...
Depois de muita busca no google e de muitas noites perdidas devido a grandes quatidades de café, consegui uma fórmula mágica...
Bem, não tão mágica, daria um pouco de trabalho, mas iria funcionar.. Vamos a ela...
O zimbra possui uma pasta onde ele armazena todos os e-mails dos usuários, "/opt/zimbra/store/0/", nesta pasta ficam os arquivos ".msg" de todos as contas, porém, cada usuário possui uma identificação, que é guardada no Mysql do zimbra (justamente o que não tava funcionando), então não tinha como saber que Id era qual usuário..
Entrando na pasta, me deparei com várias outras pastas nomeadas com a id do usuário, e dentro de cada "id" outras pastas com os ".msg" da conta...
Criei então uma conta "teste" no meu servidor zimbra com uma pasta "restaurados", e mandei converter os ".msg" para dentro dela com o seguinte comando...
/opt/zimbra/bin/zmmailbox -z -m teste@zimbrateste01.com.br addMessage /restaurados *.msg
Foi ai que percebi que era possível restaurar as mensagens que até então estavam perdidas nas contas que eu queria...
O maior trabalho foi restaurar as .msg de cada id para descobrir de quem eram aquelas mensages...
Isso demorou quase uma manha inteira, e isso que eram somente 43 contas!! (obviamente não restaurei todas as mensagens de uma conta para saber de quem eram..)
Dai parti pro shell script...
dei um "ls" na pasta com as id's ( já alteradas para os nomes dos respectivos usuários) e concatecei em um arquivo chamado "users", nesse arquivo contia então as pastas com os arquivos ".msg" e consequentemente os usuários que receberiam as mensagens...
Criei então um script que iria ler a lista de usuarios, iria criar uma pasta na conta de cada usuario da lista e também iria restaurar as mensagens de cada usuario/msg para a pasta que eu previamente havia escolhido...
O script foi rodado através de uma "screen" no linux e ficou rodando durante a noite, ao chegar na empresa pela manhã, verifiquei que todas as mensagens haviam sido restauradas..
Sendo assim, a migração das contas foi "praticamente" um sucesso, não foi "completamente" porque não foi possível salvar os "contatos, agenda, tarefas e etc..." das contas, somente as mensagens.. Mas já é alguma coisa, e o cliente ficou com as mensagens, o que sinceramente, é o mais importante né???
Deixo aqui o meu testemunho então de que é possivel restaurar os e-mails de um servidor zimbra corrompido sem ter que fazer todos os testes que eu fiz...
Ex:
Copiar pasta "store" de um servidor pro outro... (não adiantou, pois não identifica as mensagens)
Copiar pasta inteira "/opt/zimbra" - Não adiantou (ainda tive que reconfigurar o zimbra, e serviços que antes funcionavam, haviam parado!)
Se alguem estiver com o mesmo problema, só precisa entrar em contato através do meu e-mail que envio o script que faz tal tarefa...
Assinar:
Postagens (Atom)