[FUG-BR] ProFTPD IAC Remote Root Exploit
Boa noite/dia, Para quem não viu ainda... ProFTPD IAC Remote Root Exploit http://www.exploit-db.com/exploits/15449/ Testei com... FreeBSD 8.1 i386, ProFTPD 1.3.3a FreeBSD 8.0 i386, ProFTPD 1.3.2a como descrevia o exploit. http://www.leonardobotelho.com/blog/2010/11/proftpd-iac-remote-root-exploit/ abs! -- Leonardo Rota Botelho http://www.leonardobotelho.com/blog/ public key: http://www.leonardobotelho.com/leonardorotabotelho.gpg - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Harware para Cache
Isso não deveria ser um e-mail, deveria ser um artigo postado na FUG. E desculpem a resposta no topo, depois de uma explanação dessas ninguém iria encontrar meu comentário lá embaixo. 2010/11/7 Patrick Tracanelli > > On 06/11/2010 18:55, sergio wrote: > > Alguém recomenda algum hardware ou solução para cache profissional para > > provedor ? > > Sérgio, solução recomendo fortemente Lusca com Thunder Cache Pro. > > Quanto a hardware depende de muitos fatores. O principal é quantos > usuários você vai pendurar atrás desse proxy. > > O mais importante gargalo a ser evitado é o de I/O de disco. Considere > que de forma geral você tem dois limites em um disco. O mais óbvio, > espaço. O menos, número de operações por segundo (TPS). Um disco > SATA-300 de 7200rpm por exemplo vai suportar de 300 a 420TPS variando de > acordo com as taxas de operações de escrita e leitura. Isso vai resultar > numa taxa de 80MB/s a 120MB/s. > > Em um cache já rodando há alguns dias, as operações de disco são em sua > maioria (~> 75%) de leitura (o restante de escrita). Quanto mais dados > em disco, maior a taxa de operações de leitura. Óbvio. > > Com cerca de 400GB de disco alocado, seu TPS já fica acima de 300. Com > cerca de 550, 600GB provavelmente você vai bater no limite de TPS do > disco. Dessa forma imagine o que acontece se você usar um disco de 1TB > por exemplo, mas com performance SATA2/7200rpm. > > Ou seja discos muito grandes são excelente pra backup. Pra cache vão > gargalar. Então a primeira dica é ficar com discos de 500GB pra SATA2, > discos de 750GB pra SATA3 e acima disso, SAS. Claro que da pra variar um > pouco pra cima, mas já passa do ponto de segurança. > > Outra consideração é ser seletivo no que cachear. Não cachear qualquer > coisa e em especial não cachear arquivos muito pequenos. Arquivos > pequenos vão consumir seus preciosos TPS, e dependendo da taxa de uso > dos discos é mais rápido busca-los na internet do que no disco. > Atenha-se a arquivos acima de 32K. Você pode tunar isso no Lusca e no > Thunder. > > O próximo ponto é a memória. O ideal é que a placa mãe suporte a memória > em sua maior taxa barramento. Mas a velocidade nesse caso é menos > relevante que a quantidade. A regra é bem simples: quanto mais memória > melhor! > > Na FAQ do Squid existe[1] uma discussão muito boa sobre como calcular o > tamanho do seu cache_dir com base em quanto você tem de memória RAM. > > Note que a ordem é diferente do que todos pensam. Você não configura o > tamanho do cache em disco de acordo com o tamanho do seu disco. Esse é o > primeiro erro, e o principal fator de fracasso. Você define quanto usar > de cache_dir de acordo com quanto tem de RAM. É um cálculo delicado que > envolve quanto de RAM você tem, quanto será usado por MB de cache_dir, > quanto você quer usar pro cache_mem e quanto seu sistema operacional vai > consumir. > > Se colocar o Thunder na mesma máquina ainda envolve no cálculo quanto de > memória o thunder vai consumir. E isso vai variar com a sua expectativa > máxima de threads. > > Leia com muita atenção a FAQ do Squid e do Thunder[2] pra tunar isso. > > Outro ponto é que quanto mais cache_mem você puder ter, mais vai aliviar > seu disco, podendo compensar inclusive arquivos pequenos (aqueles que é > bom evitar). Mas lembre-se que cache_mem não é quanto de memória o > Lusca/Squid vão usar. É quanto de memória será usado pros Hot Objects. > > De qualquer forma se você tiver muita RAM e tunar o cache_mem pra baixo, > em tese não aproveitando a meória pros Hot Objects, no FreeBSD e graças > ao UFS_DIRHASH e também ao cache de dados do sistema de arquivo que o > FreeBSD vai fazer sozinho por padrão (kernel GENERIC), você vai ter > compensação de I/O de disco com esse cache de memória. Nesse caso, com > bastante RAM, da até pra fugir desses limites de tamanho de disco, pois > quanto mais RAM pro FreeBSD, menos TPS consumidos nos seus discos. > > Ou seja quanto você puder investir em RAM vai orientar todas as outras > suas decisões. > > Voltando aos discos, tente ter um ou dois discos pro sistema, isolados > (se for 2, em RAID-1 com gmirror), e os demais discos em RAID-0. Faça > RAID-0 com Geom Stripe. > > Faça RAID-0 com Geom Stripe. > > Sei que repeti. É pra dar ênfase ;-) Eu testei muito RAID-0 com > controladoras típicas no percado tupiniquim, em especial as P4X vendidas > com servidores HP e PERC vendidas com DELL. O RAID-0 delas não chega nem > perto em performance do Gstripe. Fuja como o diabo corre da cruz, de > RAID de BIOS. RAID de BIOS são esses RAID... de BIOS sabe? Que vem na > placa mãe. Os linuxers chamam de FakeRAID, eu chamo de qualquer RAID que > o "atacontrol" controle e o FreeBSD reconheça como ar(4). Nem considere > usar! Você tem Geom Stripe ;-) > > RAID-0 por hardware que substituiria o Gstripe só se for com > controladora LSI Logic ou QLogic. Essas podem dar mais performance que o > Gstripe. De todas que tive o prazer de testar, só elas. > > Dê uma lida na man page do stri
[FUG-BR] Tempo de execução de um script
Pessoal, É possível identificarmos o tempo que um arquivo específico (script php ou algum download) ficou sendo executado consumindo recursos do servidor? Valeu []s Emmanuel Alves - Twitter: http://www.twitter.com/emartsnet Linked In: http://www.linkedin.com/in/emartsnet - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Dicas de Servidores DNS
Coloca um PLESK ( www.plesk.com ) ou CPANEL ( www.cpanel ) no Hosting. É a melhor coisa do mundo para quem administra e para o cliente. Em 7 de novembro de 2010 10:34, Alexandre Silva Nano escreveu: > Saudações a todos da lista! > > Vou contar brevemente o meu caso: Pretendo em um futuro muito próximo > montar > meu próprio negócio de co-location, hospedagem de sites e domínios. > > A minha pergunta é: Estou em dúvida quanto às soluções DNS existentes. > > Andei pesquisando e vi que o DJBDNS é muito seguro no que se refere à > exploits e robustez, e inclusive o desenvolvedor oferece US$1000,00 para > quem conseguir achar uma brecha de segurança. Porém, não achei o DJBDNS > amigável (costume de BIND). > > Vi também o DNSCACHE, mais simples de operar e se dar manutenção, mas não > achei muita coisa relevante (será que procurei certo?). > > O que os caros amigos acham? > > Abraços. > > -- > Att, Alexandre Silva Nano > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] Distro BSD
Olás! Gostaria de saber se há algum material (além do achado no DuckGo) sobre criar distros BSD. Já faz um tempo que venho tentando criar uma distro bem leve com Xvesa (kdrive, tinyX) usando BSD assim como o TinyCoreLinux mas o material que acho é sempre muito antigo e escasso... Alguém já precisou criar uma distro ou refinar tanto o FreeBSD e gerar um CD/DVD dele? Obrigado! Zendrael www.zendrael.com.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Dicas de Servidores DNS
A questao que o amigo se refere, nao eh de uma interface web para gerenciar o servidor de nomes, e sim uma interface amigavel onde o cliente (aquele que paga pela hospedagem) posso gerir seu dominio com o minimo de conhecimento. Isso eu acho muito mais facil desenvolver conforme a necessidade do que ficar tentando se adaptar com coisas prontas. m3 Em 7 de novembro de 2010 20:29, Anderson Alves de Albuquerque escreveu: > O DJBdns vc pode utilizar interface gráfica para ajudar, eu lembro > que existe uma. > > Eu utilizo o djbdns e nunca tive problemas, mas cada caso eh um caso. > > > Em 7 de novembro de 2010 18:58, TIsOrA Wilson Rogerio Lopes > escreveu: >> >> Como a intenção é hospedagem de domínios, questões importantes a serem >> avaliadas são a forma de provisionamento (como adicionar de forma >> automatizada os domínios no master e nos slaves) e armazenamento disso >> (arquivos no file system ou base de dados). >> Na questão provisionamento, o bind a partir da versão 9.7.2 permite a adição >> e remoção de zonas via rndc, que pode ser bastante util nesse caso. Até >> então a forma tradicional de adicionar uma nova zona seria editar o arquivo >> de configuração ou usar algum esquema de scp, rsync, etc..., tanto no master >> quanto nos slaves. A inserção dos records nas zonas pode continuar >> normalmente somente no master e os slaves recebendo via xfr. >> Quanto à forma de armazenamento da informação, a forma tradicional de >> armazenamento em arquivo no file system pode ser um problema para >> administração, principalmente quando se precisa de um processo automatizado >> e de uma interação com alguma ferramenta web que você deve fornecer aos seus >> clientes para adição/remoção de zonas e resource records. Pelo menos no >> master seria interessante pensar em armazenamento em base de dados. >> >>> Date: Sun, 7 Nov 2010 11:59:33 -0200 >>> From: pe...@madnix.com >>> To: freebsd@fug.com.br >>> Subject: Re: [FUG-BR] Dicas de Servidores DNS >>> >>> O BIND está muito seguro mesmo, os problemas que ele ainda enfrenta são >>> questões do protocolo, que todas as soluções também estão sujeitas. Vá de >>> BIND. :) >>> >>> Em 7 de novembro de 2010 11:25, Alexandre Silva Nano >>> escreveu: >>> >>> > Muito obrigado! >>> > >>> > Em 7 de novembro de 2010 04:43, Mario Augusto Mania >>> > escreveu: >>> > >>> > > Cara... o bind esta muito seguro. Passado eh passado! >>> > > >>> > > m3 >>> > > >>> > > Em 7 de novembro de 2010 10:34, Alexandre Silva Nano >>> > > escreveu: >>> > > > Saudações a todos da lista! >>> > > > >>> > > > Vou contar brevemente o meu caso: Pretendo em um futuro muito próximo >>> > > montar >>> > > > meu próprio negócio de co-location, hospedagem de sites e domínios. >>> > > > >>> > > > A minha pergunta é: Estou em dúvida quanto às soluções DNS existentes. >>> > > > >>> > > > Andei pesquisando e vi que o DJBDNS é muito seguro no que se refere à >>> > > > exploits e robustez, e inclusive o desenvolvedor oferece US$1000,00 >>> > para >>> > > > quem conseguir achar uma brecha de segurança. Porém, não achei o >>> > > > DJBDNS >>> > > > amigável (costume de BIND). >>> > > > >>> > > > Vi também o DNSCACHE, mais simples de operar e se dar manutenção, mas >>> > não >>> > > > achei muita coisa relevante (será que procurei certo?). >>> > > > >>> > > > O que os caros amigos acham? >>> > > > >>> > > > Abraços. >>> > > > >>> > > > -- >>> > > > Att, Alexandre Silva Nano >>> > > > - >>> > > > Histórico: http://www.fug.com.br/historico/html/freebsd/ >>> > > > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >>> > > > >>> > > >>> > > >>> > > >>> > > -- >>> > > Atenciosmente >>> > > >>> > > Mario Augusto Mania >>> > > --- >>> > > m3.bsd.ma...@gmail.com >>> > > Cel.: (43) 9938-9629 >>> > > Msn: ma...@oquei.com >>> > > - >>> > > Histórico: http://www.fug.com.br/historico/html/freebsd/ >>> > > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >>> > > >>> > >>> > >>> > >>> > -- >>> > Att, Alexandre Silva Nano >>> > Tels.: (71)3017-5308 / (71)9947-0430 / (71)8710-6422 >>> > - >>> > Histórico: http://www.fug.com.br/historico/html/freebsd/ >>> > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >>> > >>> - >>> Histórico: http://www.fug.com.br/historico/html/freebsd/ >>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >> >> - >> Histórico: http://www.fug.com.br/historico/html/freebsd/ >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >> > > > > -- > [], Anderson Alves de Albuquerque. > --- > E-mails: andersonalvesdealbuquerque#hotmail.com (replace # by @) > andersonaa#gmail.com (replace # by @) > ICQ: 73222660 > http://diseg.pu.ufrj.br/ > --- > ---
Re: [FUG-BR] Dicas de Servidores DNS
O DJBdns vc pode utilizar interface gráfica para ajudar, eu lembro que existe uma. Eu utilizo o djbdns e nunca tive problemas, mas cada caso eh um caso. Em 7 de novembro de 2010 18:58, TIsOrA Wilson Rogerio Lopes escreveu: > > Como a intenção é hospedagem de domínios, questões importantes a serem > avaliadas são a forma de provisionamento (como adicionar de forma > automatizada os domínios no master e nos slaves) e armazenamento disso > (arquivos no file system ou base de dados). > Na questão provisionamento, o bind a partir da versão 9.7.2 permite a adição > e remoção de zonas via rndc, que pode ser bastante util nesse caso. Até então > a forma tradicional de adicionar uma nova zona seria editar o arquivo de > configuração ou usar algum esquema de scp, rsync, etc..., tanto no master > quanto nos slaves. A inserção dos records nas zonas pode continuar > normalmente somente no master e os slaves recebendo via xfr. > Quanto à forma de armazenamento da informação, a forma tradicional de > armazenamento em arquivo no file system pode ser um problema para > administração, principalmente quando se precisa de um processo automatizado e > de uma interação com alguma ferramenta web que você deve fornecer aos seus > clientes para adição/remoção de zonas e resource records. Pelo menos no > master seria interessante pensar em armazenamento em base de dados. > >> Date: Sun, 7 Nov 2010 11:59:33 -0200 >> From: pe...@madnix.com >> To: freebsd@fug.com.br >> Subject: Re: [FUG-BR] Dicas de Servidores DNS >> >> O BIND está muito seguro mesmo, os problemas que ele ainda enfrenta são >> questões do protocolo, que todas as soluções também estão sujeitas. Vá de >> BIND. :) >> >> Em 7 de novembro de 2010 11:25, Alexandre Silva Nano >> escreveu: >> >> > Muito obrigado! >> > >> > Em 7 de novembro de 2010 04:43, Mario Augusto Mania >> > escreveu: >> > >> > > Cara... o bind esta muito seguro. Passado eh passado! >> > > >> > > m3 >> > > >> > > Em 7 de novembro de 2010 10:34, Alexandre Silva Nano >> > > escreveu: >> > > > Saudações a todos da lista! >> > > > >> > > > Vou contar brevemente o meu caso: Pretendo em um futuro muito próximo >> > > montar >> > > > meu próprio negócio de co-location, hospedagem de sites e domínios. >> > > > >> > > > A minha pergunta é: Estou em dúvida quanto às soluções DNS existentes. >> > > > >> > > > Andei pesquisando e vi que o DJBDNS é muito seguro no que se refere à >> > > > exploits e robustez, e inclusive o desenvolvedor oferece US$1000,00 >> > para >> > > > quem conseguir achar uma brecha de segurança. Porém, não achei o DJBDNS >> > > > amigável (costume de BIND). >> > > > >> > > > Vi também o DNSCACHE, mais simples de operar e se dar manutenção, mas >> > não >> > > > achei muita coisa relevante (será que procurei certo?). >> > > > >> > > > O que os caros amigos acham? >> > > > >> > > > Abraços. >> > > > >> > > > -- >> > > > Att, Alexandre Silva Nano >> > > > - >> > > > Histórico: http://www.fug.com.br/historico/html/freebsd/ >> > > > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >> > > > >> > > >> > > >> > > >> > > -- >> > > Atenciosmente >> > > >> > > Mario Augusto Mania >> > > --- >> > > m3.bsd.ma...@gmail.com >> > > Cel.: (43) 9938-9629 >> > > Msn: ma...@oquei.com >> > > - >> > > Histórico: http://www.fug.com.br/historico/html/freebsd/ >> > > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >> > > >> > >> > >> > >> > -- >> > Att, Alexandre Silva Nano >> > Tels.: (71)3017-5308 / (71)9947-0430 / (71)8710-6422 >> > - >> > Histórico: http://www.fug.com.br/historico/html/freebsd/ >> > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >> > >> - >> Histórico: http://www.fug.com.br/historico/html/freebsd/ >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > -- [], Anderson Alves de Albuquerque. --- E-mails: andersonalvesdealbuquerque#hotmail.com (replace # by @) andersonaa#gmail.com (replace # by @) ICQ: 73222660 http://diseg.pu.ufrj.br/ --- - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Dicas de Servidores DNS
Como a intenção é hospedagem de domínios, questões importantes a serem avaliadas são a forma de provisionamento (como adicionar de forma automatizada os domínios no master e nos slaves) e armazenamento disso (arquivos no file system ou base de dados). Na questão provisionamento, o bind a partir da versão 9.7.2 permite a adição e remoção de zonas via rndc, que pode ser bastante util nesse caso. Até então a forma tradicional de adicionar uma nova zona seria editar o arquivo de configuração ou usar algum esquema de scp, rsync, etc..., tanto no master quanto nos slaves. A inserção dos records nas zonas pode continuar normalmente somente no master e os slaves recebendo via xfr. Quanto à forma de armazenamento da informação, a forma tradicional de armazenamento em arquivo no file system pode ser um problema para administração, principalmente quando se precisa de um processo automatizado e de uma interação com alguma ferramenta web que você deve fornecer aos seus clientes para adição/remoção de zonas e resource records. Pelo menos no master seria interessante pensar em armazenamento em base de dados. > Date: Sun, 7 Nov 2010 11:59:33 -0200 > From: pe...@madnix.com > To: freebsd@fug.com.br > Subject: Re: [FUG-BR] Dicas de Servidores DNS > > O BIND está muito seguro mesmo, os problemas que ele ainda enfrenta são > questões do protocolo, que todas as soluções também estão sujeitas. Vá de > BIND. :) > > Em 7 de novembro de 2010 11:25, Alexandre Silva Nano > escreveu: > > > Muito obrigado! > > > > Em 7 de novembro de 2010 04:43, Mario Augusto Mania > > escreveu: > > > > > Cara... o bind esta muito seguro. Passado eh passado! > > > > > > m3 > > > > > > Em 7 de novembro de 2010 10:34, Alexandre Silva Nano > > > escreveu: > > > > Saudações a todos da lista! > > > > > > > > Vou contar brevemente o meu caso: Pretendo em um futuro muito próximo > > > montar > > > > meu próprio negócio de co-location, hospedagem de sites e domínios. > > > > > > > > A minha pergunta é: Estou em dúvida quanto às soluções DNS existentes. > > > > > > > > Andei pesquisando e vi que o DJBDNS é muito seguro no que se refere à > > > > exploits e robustez, e inclusive o desenvolvedor oferece US$1000,00 > > para > > > > quem conseguir achar uma brecha de segurança. Porém, não achei o DJBDNS > > > > amigável (costume de BIND). > > > > > > > > Vi também o DNSCACHE, mais simples de operar e se dar manutenção, mas > > não > > > > achei muita coisa relevante (será que procurei certo?). > > > > > > > > O que os caros amigos acham? > > > > > > > > Abraços. > > > > > > > > -- > > > > Att, Alexandre Silva Nano > > > > - > > > > Histórico: http://www.fug.com.br/historico/html/freebsd/ > > > > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > > > > > > > > > > > > > > > > -- > > > Atenciosmente > > > > > > Mario Augusto Mania > > > --- > > > m3.bsd.ma...@gmail.com > > > Cel.: (43) 9938-9629 > > > Msn: ma...@oquei.com > > > - > > > Histórico: http://www.fug.com.br/historico/html/freebsd/ > > > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > > > > > > > > > > > -- > > Att, Alexandre Silva Nano > > Tels.: (71)3017-5308 / (71)9947-0430 / (71)8710-6422 > > - > > Histórico: http://www.fug.com.br/historico/html/freebsd/ > > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > > > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Regras PF
Em Sun, 7 Nov 2010 16:53:13 -0300 Thiago Gomes , conhecido consumidor/usuário de drogas (Windows e BigMac com Coke) escreveu: > > Irado.. nao é webmin que. é outra aplicação feita aqui .. opsss.. ato falho (rs), desculpe a interferencia. -- saudações, irado furioso com tudo Linux User 179402/FreeBSD BSD50853/FUG-BR 154 Não uso drogas - 100% Miko$hit-free Deus e o Diabo oferecem a mesma mercadoria: a felicidade. A diferença é que Deus cobra adiantado. [Anônimo] - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Regras PF
Irado.. nao é webmin que. é outra aplicação feita aqui ..
Em 7 de novembro de 2010 16:44, irado furioso com tudo
escreveu:
> Em Sun, 7 Nov 2010 16:26:00 -0300
> Thiago Gomes , conhecido consumidor/usuário de
> drogas (Windows e BigMac com Coke) escreveu:
>
>> # WebAdmin = unico acesso com a maquina 10.0.0.150
>> pass in log on $int_if proto tcp from 10.0.0.150 to $int_if port
>> { www https } block in log on $int_if proto tcp from $int_net to
>> $int_if port { www https }
>
> não sei se entendi bem, mas acontece que o webmin acessa a porta 1
> e não 80/443, normalmente. comentário: normalmente eu bloqueio acesso
> "to me" diretamente e não a (por ex) $int_net que imagino seja sua
> interface. O "to me" (creio) é mais restritivo, em termos de
> administração.
>
>
> --
> saudações,
> irado furioso com tudo
> Linux User 179402/FreeBSD BSD50853/FUG-BR 154
> Não uso drogas - 100% Miko$hit-free
> Rico com chofer: Milionário
> Pobre com chofer: Preso
> -
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>
--
Thiago Gomes
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Regras PF
Em Sun, 7 Nov 2010 16:26:00 -0300
Thiago Gomes , conhecido consumidor/usuário de
drogas (Windows e BigMac com Coke) escreveu:
> # WebAdmin = unico acesso com a maquina 10.0.0.150
> pass in log on $int_if proto tcp from 10.0.0.150 to $int_if port
> { www https } block in log on $int_if proto tcp from $int_net to
> $int_if port { www https }
não sei se entendi bem, mas acontece que o webmin acessa a porta 1
e não 80/443, normalmente. comentário: normalmente eu bloqueio acesso
"to me" diretamente e não a (por ex) $int_net que imagino seja sua
interface. O "to me" (creio) é mais restritivo, em termos de
administração.
--
saudações,
irado furioso com tudo
Linux User 179402/FreeBSD BSD50853/FUG-BR 154
Não uso drogas - 100% Miko$hit-free
Rico com chofer: Milionário
Pobre com chofer: Preso
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] Regras PF
Pessoal,
Estou tentando configurar umas regras PF que somente uma maquina tenha
acessoa a inteface web do servidor.
porem nao estou conseguindo fazer esse bloqueio, o que esta errado ??
int_if = "rl0"
ext_if = "vr0"
int_net = "10.0.0.0/16"
set loginterface $int_if
set skip on lo
# WebAdmin = unico acesso com a maquina 10.0.0.150
pass in log on $int_if proto tcp from 10.0.0.150 to $int_if port { www https }
block in log on $int_if proto tcp from $int_net to $int_if port { www https }
# ping
block in log on $int_if proto icmp from $int_net to $int_net
--
Thiago Gomes
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Harware para Cache
2010/11/7 Patrick Tracanelli : > On 06/11/2010 18:55, sergio wrote: >> Alguém recomenda algum hardware ou solução para cache profissional para >> provedor ? > > Sérgio, solução recomendo fortemente Lusca com Thunder Cache Pro. > > Quanto a hardware depende de muitos fatores. O principal é quantos > usuários você vai pendurar atrás desse proxy. > > O mais importante gargalo a ser evitado é o de I/O de disco. Considere > que de forma geral você tem dois limites em um disco. O mais óbvio, > espaço. O menos, número de operações por segundo (TPS). Um disco > SATA-300 de 7200rpm por exemplo vai suportar de 300 a 420TPS variando de > acordo com as taxas de operações de escrita e leitura. Isso vai resultar > numa taxa de 80MB/s a 120MB/s. > > Em um cache já rodando há alguns dias, as operações de disco são em sua > maioria (~> 75%) de leitura (o restante de escrita). Quanto mais dados > em disco, maior a taxa de operações de leitura. Óbvio. > > Com cerca de 400GB de disco alocado, seu TPS já fica acima de 300. Com > cerca de 550, 600GB provavelmente você vai bater no limite de TPS do > disco. Dessa forma imagine o que acontece se você usar um disco de 1TB > por exemplo, mas com performance SATA2/7200rpm. > > Ou seja discos muito grandes são excelente pra backup. Pra cache vão > gargalar. Então a primeira dica é ficar com discos de 500GB pra SATA2, > discos de 750GB pra SATA3 e acima disso, SAS. Claro que da pra variar um > pouco pra cima, mas já passa do ponto de segurança. > > Outra consideração é ser seletivo no que cachear. Não cachear qualquer > coisa e em especial não cachear arquivos muito pequenos. Arquivos > pequenos vão consumir seus preciosos TPS, e dependendo da taxa de uso > dos discos é mais rápido busca-los na internet do que no disco. > Atenha-se a arquivos acima de 32K. Você pode tunar isso no Lusca e no > Thunder. > > O próximo ponto é a memória. O ideal é que a placa mãe suporte a memória > em sua maior taxa barramento. Mas a velocidade nesse caso é menos > relevante que a quantidade. A regra é bem simples: quanto mais memória > melhor! > > Na FAQ do Squid existe[1] uma discussão muito boa sobre como calcular o > tamanho do seu cache_dir com base em quanto você tem de memória RAM. > > Note que a ordem é diferente do que todos pensam. Você não configura o > tamanho do cache em disco de acordo com o tamanho do seu disco. Esse é o > primeiro erro, e o principal fator de fracasso. Você define quanto usar > de cache_dir de acordo com quanto tem de RAM. É um cálculo delicado que > envolve quanto de RAM você tem, quanto será usado por MB de cache_dir, > quanto você quer usar pro cache_mem e quanto seu sistema operacional vai > consumir. > > Se colocar o Thunder na mesma máquina ainda envolve no cálculo quanto de > memória o thunder vai consumir. E isso vai variar com a sua expectativa > máxima de threads. > > Leia com muita atenção a FAQ do Squid e do Thunder[2] pra tunar isso. > > Outro ponto é que quanto mais cache_mem você puder ter, mais vai aliviar > seu disco, podendo compensar inclusive arquivos pequenos (aqueles que é > bom evitar). Mas lembre-se que cache_mem não é quanto de memória o > Lusca/Squid vão usar. É quanto de memória será usado pros Hot Objects. > > De qualquer forma se você tiver muita RAM e tunar o cache_mem pra baixo, > em tese não aproveitando a meória pros Hot Objects, no FreeBSD e graças > ao UFS_DIRHASH e também ao cache de dados do sistema de arquivo que o > FreeBSD vai fazer sozinho por padrão (kernel GENERIC), você vai ter > compensação de I/O de disco com esse cache de memória. Nesse caso, com > bastante RAM, da até pra fugir desses limites de tamanho de disco, pois > quanto mais RAM pro FreeBSD, menos TPS consumidos nos seus discos. > > Ou seja quanto você puder investir em RAM vai orientar todas as outras > suas decisões. O Squid, e seus similares, pedem muita memória RAM. Eu reafirmo o que está aqui. coloque MUITA RAM. > > Voltando aos discos, tente ter um ou dois discos pro sistema, isolados > (se for 2, em RAID-1 com gmirror), e os demais discos em RAID-0. Faça > RAID-0 com Geom Stripe. > > Faça RAID-0 com Geom Stripe. Aqui eu faria diferente. Os discos de sistema com mirror, e um disco para cada cache, ou um par de discos para cada cache em mirror. O mirror pode melhorar a leitura, mas pode piorar um pouco a escrita. O RAID 0 pode não funcionar tão bem quando os discos estarem completamente separados. Outra coisa que pode aumentar muito o desempenho, mas sugiro para caches muito ocupadas, é usar discos de estado sólido, ou discos SAS de 15 mil RPMs. Eles tem um nível de TPS bem alto. > > Sei que repeti. É pra dar ênfase ;-) Eu testei muito RAID-0 com > controladoras típicas no percado tupiniquim, em especial as P4X vendidas > com servidores HP e PERC vendidas com DELL. O RAID-0 delas não chega nem > perto em performance do Gstripe. Fuja como o diabo corre da cruz, de > RAID de BIOS. RAID de BIOS são esses RAID... de BIOS sabe? Que vem na > placa mãe. Os linuxer
Re: [FUG-BR] newfs para disco de 1TB
2010/11/4 Patrick Tracanelli : > > Em 04/11/2010, às 10:03, Renato Frederick escreveu: > >> Chute aqui, desculpa se for bobagem: >> >> >> Não teria nada a ver com a BIOS não? HD muito grande em PC relativamente >> velho? >> >> lembro que em 1900 e bolinha tinha BIOS que não achava HD grande e dava >> mensagens exóticas assim :) > > Pois é, pode ser sim, nesse caso limite da controladora ou ainda o cabo, ja > que é um erro de CRC de acordo com os logs. > > ICRC shall be set to one if an interface CRC error has occurred > during an Ultra DMA data transfer. The content of this bit is not > applicable for Multiword DMA transfers. > > Uma outra opção de teste é a Renata desabilitar udma. > > Nesse caso Renata boote com: > > hw.ata.ata_dma=0 > > (via loader prompt ou no loader.conf) > > E tente o newfs. Se funcionar é cabo ou conjunto. Se der problema certamente > é disco mesmo. Cabo pode ser. Pelo número do HD parece ser SATA, e já vi cabo SATA ruim. verifique se o cabo de força está bem conectado, mas acho que aí a pane seria pior. Controladora é mais chato or que não se troca com a mesma facilidade que se troca o cabo. João Rocha. > > > >> >> []s >> >> >> >> >> >> -Mensagem Original- >> From: Patrick Tracanelli >> Sent: Thursday, November 04, 2010 9:22 AM >> To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) >> Subject: Re: [FUG-BR] newfs para disco de 1TB >> >> >> Em 04/11/2010, às 09:18, Renata Dias escreveu: >> >>> Patrick, >>> >>> Particionei o disco utilizando apenas 100GB e não obtive erro. >>> Posso concluir então que o erro está em alguns setores do disco e não na >>> controladora ou cabo? >> >> Os erros são sim em posições mais altas da geometria de acordo com os logs, >> mas se quiser tirar a limpo mesmo use o stress rodando simultaneamente >> operações de read e write nesse disco, com esses 100GB iniciais. >> >>> >>> Obrigada. >>> >>> >>> >>> Em 4 de novembro de 2010 09:09, Patrick Tracanelli < >>> eks...@freebsdbrasil.com.br> escreveu: >>> Em 04/11/2010, às 09:04, Renata Dias escreveu: > Caros, > > Adicionei ao servidor FreeBSD 7.2-STABLE um disco de 1TB, porém na hora de > criar a partição recebo um erro inesperado. > > DISCO: > ad7: 953869MB at ata3-slave SATA150 > > > ERRO: > ad7: WARNING - WRITE_DMA UDMA ICRC error (retrying request) > LBA=196832319 > ad7: WARNING - WRITE_DMA UDMA ICRC error (retrying request) > LBA=234467519 > ad7: WARNING - WRITE_DMA48 UDMA ICRC error (retrying request) LBA=290920319 > ad7: FAILURE - WRITE_DMA48 status=51 > error=10 LBA=290920319 > > Preciso atualizar o FreeeBSD pra 8.0? Alterar alguma opção na BIOS? Não Renata, o problema é fisico mesmo. Ou disco ou conjunto. Felizmente o FreeBSD testa os superblocks com um lookup direto. Se fosse Windows ou Linux a formatação poderia passar e depois começar travar ou perder dados em produção. Se o disco for novo cheque cabos, controladora... > > Obrigada; > > > -- > Renata Dias > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Patrick Tracanelli FreeBSD Brasil LTDA. Tel.: (31) 3516-0800 316...@sip.freebsdbrasil.com.br http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!" - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >>> >>> >>> >>> -- >>> Renata Dias >>> - >>> Histórico: http://www.fug.com.br/historico/html/freebsd/ >>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >> >> -- >> Patrick Tracanelli >> >> FreeBSD Brasil LTDA. >> Tel.: (31) 3516-0800 >> 316...@sip.freebsdbrasil.com.br >> http://www.freebsdbrasil.com.br >> "Long live Hanin Elias, Kim Deal!" >> >> - >> Histórico: http://www.fug.com.br/historico/html/freebsd/ >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >> >> - >> Histórico: http://www.fug.com.br/historico/html/freebsd/ >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > > -- > Patrick Tracanelli > > FreeBSD Brasil LTDA. > Tel.: (31) 3516-0800 > 316...@sip.freebsdbrasil.com.br > http://www.freebsdbrasil.com.br > "Long live Hanin Elias, Kim Deal!" > > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > -- "Sempre se apanha mais com as menores besteiras. Experiência própria." http://jgoffredo.blogspot.com goffr...@gmail.com - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] newfs para disco de 1TB
2010/11/4 Renato Frederick : > Chute aqui, desculpa se for bobagem: > > > Não teria nada a ver com a BIOS não? HD muito grande em PC relativamente > velho? > > lembro que em 1900 e bolinha tinha BIOS que não achava HD grande e dava > mensagens exóticas assim :) Não é BIOS. A BIOS do meu K6 II 300 não sabe que tem um HD de 250 GB. Se eu coloco um HD de mais de 30 GB e mando ela achar ela tem um troço e morre, trava. Mas o FreeBSD funciona direitinho, dando boot do HD de 30 GB e montando o resto. Eu sugiro instalar o /usr/ports/sysutils/smartmontools/ e testar o HD com ele. Este programa lê as informações de auto teste do HD e as exibe. Eu uso HDs internos e USB de 1.5 TB no meu FreeBSD 7.3-STABLE sem problemas. E já coloquei um HD 1.5 TB em um FreeBSD 6.4 via USB sem problemas. Pelo que vi na mensagem, parece ser defeito físico. Tem um teste não destrutivo que pode fazer no disco, as demora um pouco: dd if=/dev/ad of=/dev/null bs=1048576 Isto lerá o disco inteiro, o que deve testar se tem problemas. E tem o DESTRUTIVO, que causa PERDA de conteúdo: dd if=/dev/zero of=/dev/ad bs=1048576 O segundo tem que ser feito com o disco desmontado, mas acho que o primeiro não precisa fazer o umount. João Rocha. > > []s > > > > > > -Mensagem Original- > From: Patrick Tracanelli > Sent: Thursday, November 04, 2010 9:22 AM > To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) > Subject: Re: [FUG-BR] newfs para disco de 1TB > > > Em 04/11/2010, às 09:18, Renata Dias escreveu: > >> Patrick, >> >> Particionei o disco utilizando apenas 100GB e não obtive erro. >> Posso concluir então que o erro está em alguns setores do disco e não na >> controladora ou cabo? > > Os erros são sim em posições mais altas da geometria de acordo com os logs, > mas se quiser tirar a limpo mesmo use o stress rodando simultaneamente > operações de read e write nesse disco, com esses 100GB iniciais. > >> >> Obrigada. >> >> >> >> Em 4 de novembro de 2010 09:09, Patrick Tracanelli < >> eks...@freebsdbrasil.com.br> escreveu: >> >>> >>> Em 04/11/2010, às 09:04, Renata Dias escreveu: >>> Caros, Adicionei ao servidor FreeBSD 7.2-STABLE um disco de 1TB, porém na hora >>> de criar a partição recebo um erro inesperado. DISCO: ad7: 953869MB at ata3-slave SATA150 ERRO: ad7: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=196832319 ad7: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=234467519 ad7: WARNING - WRITE_DMA48 UDMA ICRC error (retrying request) >>> LBA=290920319 ad7: FAILURE - WRITE_DMA48 status=51 error=10 LBA=290920319 Preciso atualizar o FreeeBSD pra 8.0? Alterar alguma opção na BIOS? >>> >>> Não Renata, o problema é fisico mesmo. Ou disco ou conjunto. Felizmente o >>> FreeBSD testa os superblocks com um lookup direto. Se fosse Windows ou >>> Linux >>> a formatação poderia passar e depois começar travar ou perder dados em >>> produção. >>> >>> Se o disco for novo cheque cabos, controladora... >>> Obrigada; -- Renata Dias - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >>> >>> -- >>> Patrick Tracanelli >>> >>> FreeBSD Brasil LTDA. >>> Tel.: (31) 3516-0800 >>> 316...@sip.freebsdbrasil.com.br >>> http://www.freebsdbrasil.com.br >>> "Long live Hanin Elias, Kim Deal!" >>> >>> - >>> Histórico: http://www.fug.com.br/historico/html/freebsd/ >>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >>> >> >> >> >> -- >> Renata Dias >> - >> Histórico: http://www.fug.com.br/historico/html/freebsd/ >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > > -- > Patrick Tracanelli > > FreeBSD Brasil LTDA. > Tel.: (31) 3516-0800 > 316...@sip.freebsdbrasil.com.br > http://www.freebsdbrasil.com.br > "Long live Hanin Elias, Kim Deal!" > > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > -- "Sempre se apanha mais com as menores besteiras. Experiência própria." http://jgoffredo.blogspot.com goffr...@gmail.com - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Harware para Cache
On 07/11/2010 03:58, sergio wrote: > Patrick, muito obrigado pelas informações, neste caso de usar o Lusca com > Thunder Cache Pro com FreeBSD, estou pensando se vale a pena fazer o > redirecionamento para porta http apartir de um roteador Mikrotik ou se devo > usar o FreeBSD como roteador/cache. Da na mesma. Ambas topologias são igualmente funcionais. Em poucos casos vi o MK sobrecarregando com as regras de mangle. Mas pq ja estava sobrecarregado mesmo hehe. So piorou. > A última vez que tentei usar o o Cache com um Link de 300Mbps, um Mikrotik > redirecionando o tráfego http para uma máquina com FreeBSD + Lusca + Thunder > Cache tive problema com I/O de disco (Disco SAS), acabei não focando mais > nisso, mas estou com vontade de voltar. Pois é. Certamente o problema de I/O de disco aconteceria em qualquer topologia. Mal dimensionamento :( > Fiz testes de download em um circuito da Intelig com 100Mbps de banda livre e > tive uma taxa de transferência variando entre 20Mbps e 38Mbps, já em um > circuito da GVT com 50Mbps tive uma taxa entre 40Mbps e 50Mbps. Não entendi. Taxas de economia? > É notável que a GVT tem muitos Cache, notamos que os downloads pela GVT > geralmente são mais rápidos, atingem taxas de transferência altas mais > rapidamente etc. O cache da GVT não é transparente. É baseado em rewrite. Dai a importância de usar o thunder. Tem plugins pra GVT que sem eles você perde o cache que a GVT faz. > > >> -Original Message- >> From: eks...@freebsdbrasil.com.br >> Sent: Sun, 07 Nov 2010 03:30:33 -0200 >> To: freebsd@fug.com.br >> Subject: Re: [FUG-BR] Harware para Cache >> >> On 06/11/2010 18:55, sergio wrote: >>> Alguém recomenda algum hardware ou solução para cache profissional para >>> provedor ? >> >> Sérgio, solução recomendo fortemente Lusca com Thunder Cache Pro. >> >> Quanto a hardware depende de muitos fatores. O principal é quantos >> usuários você vai pendurar atrás desse proxy. >> >> O mais importante gargalo a ser evitado é o de I/O de disco. Considere >> que de forma geral você tem dois limites em um disco. O mais óbvio, >> espaço. O menos, número de operações por segundo (TPS). Um disco >> SATA-300 de 7200rpm por exemplo vai suportar de 300 a 420TPS variando de >> acordo com as taxas de operações de escrita e leitura. Isso vai resultar >> numa taxa de 80MB/s a 120MB/s. >> >> Em um cache já rodando há alguns dias, as operações de disco são em sua >> maioria (~> 75%) de leitura (o restante de escrita). Quanto mais dados >> em disco, maior a taxa de operações de leitura. Óbvio. >> >> Com cerca de 400GB de disco alocado, seu TPS já fica acima de 300. Com >> cerca de 550, 600GB provavelmente você vai bater no limite de TPS do >> disco. Dessa forma imagine o que acontece se você usar um disco de 1TB >> por exemplo, mas com performance SATA2/7200rpm. >> >> Ou seja discos muito grandes são excelente pra backup. Pra cache vão >> gargalar. Então a primeira dica é ficar com discos de 500GB pra SATA2, >> discos de 750GB pra SATA3 e acima disso, SAS. Claro que da pra variar um >> pouco pra cima, mas já passa do ponto de segurança. >> >> Outra consideração é ser seletivo no que cachear. Não cachear qualquer >> coisa e em especial não cachear arquivos muito pequenos. Arquivos >> pequenos vão consumir seus preciosos TPS, e dependendo da taxa de uso >> dos discos é mais rápido busca-los na internet do que no disco. >> Atenha-se a arquivos acima de 32K. Você pode tunar isso no Lusca e no >> Thunder. >> >> O próximo ponto é a memória. O ideal é que a placa mãe suporte a memória >> em sua maior taxa barramento. Mas a velocidade nesse caso é menos >> relevante que a quantidade. A regra é bem simples: quanto mais memória >> melhor! >> >> Na FAQ do Squid existe[1] uma discussão muito boa sobre como calcular o >> tamanho do seu cache_dir com base em quanto você tem de memória RAM. >> >> Note que a ordem é diferente do que todos pensam. Você não configura o >> tamanho do cache em disco de acordo com o tamanho do seu disco. Esse é o >> primeiro erro, e o principal fator de fracasso. Você define quanto usar >> de cache_dir de acordo com quanto tem de RAM. É um cálculo delicado que >> envolve quanto de RAM você tem, quanto será usado por MB de cache_dir, >> quanto você quer usar pro cache_mem e quanto seu sistema operacional vai >> consumir. >> >> Se colocar o Thunder na mesma máquina ainda envolve no cálculo quanto de >> memória o thunder vai consumir. E isso vai variar com a sua expectativa >> máxima de threads. >> >> Leia com muita atenção a FAQ do Squid e do Thunder[2] pra tunar isso. >> >> Outro ponto é que quanto mais cache_mem você puder ter, mais vai aliviar >> seu disco, podendo compensar inclusive arquivos pequenos (aqueles que é >> bom evitar). Mas lembre-se que cache_mem não é quanto de memória o >> Lusca/Squid vão usar. É quanto de memória será usado pros Hot Objects. >> >> De qualquer forma se você tiver muita RAM e tunar o cache_mem pra baixo, >> em tese não aprov
Re: [FUG-BR] Harware para Cache
On 07/11/2010 09:47, Levi Lins wrote: > > > > > Patrick, e ZFS? Nunca tive vantagens. Performance abaixo do gstripe. > > >> Date: Sun, 7 Nov 2010 03:30:33 -0200 >> From: eks...@freebsdbrasil.com.br >> To: freebsd@fug.com.br >> Subject: Re: [FUG-BR] Harware para Cache >> >> On 06/11/2010 18:55, sergio wrote: >>> Alguém recomenda algum hardware ou solução para cache profissional para >>> provedor ? >> >> Sérgio, solução recomendo fortemente Lusca com Thunder Cache Pro. >> >> Quanto a hardware depende de muitos fatores. O principal é quantos >> usuários você vai pendurar atrás desse proxy. >> >> O mais importante gargalo a ser evitado é o de I/O de disco. Considere >> que de forma geral você tem dois limites em um disco. O mais óbvio, >> espaço. O menos, número de operações por segundo (TPS). Um disco >> SATA-300 de 7200rpm por exemplo vai suportar de 300 a 420TPS variando de >> acordo com as taxas de operações de escrita e leitura. Isso vai resultar >> numa taxa de 80MB/s a 120MB/s. >> >> Em um cache já rodando há alguns dias, as operações de disco são em sua >> maioria (~> 75%) de leitura (o restante de escrita). Quanto mais dados >> em disco, maior a taxa de operações de leitura. Óbvio. >> >> Com cerca de 400GB de disco alocado, seu TPS já fica acima de 300. Com >> cerca de 550, 600GB provavelmente você vai bater no limite de TPS do >> disco. Dessa forma imagine o que acontece se você usar um disco de 1TB >> por exemplo, mas com performance SATA2/7200rpm. >> >> Ou seja discos muito grandes são excelente pra backup. Pra cache vão >> gargalar. Então a primeira dica é ficar com discos de 500GB pra SATA2, >> discos de 750GB pra SATA3 e acima disso, SAS. Claro que da pra variar um >> pouco pra cima, mas já passa do ponto de segurança. >> >> Outra consideração é ser seletivo no que cachear. Não cachear qualquer >> coisa e em especial não cachear arquivos muito pequenos. Arquivos >> pequenos vão consumir seus preciosos TPS, e dependendo da taxa de uso >> dos discos é mais rápido busca-los na internet do que no disco. >> Atenha-se a arquivos acima de 32K. Você pode tunar isso no Lusca e no >> Thunder. >> >> O próximo ponto é a memória. O ideal é que a placa mãe suporte a memória >> em sua maior taxa barramento. Mas a velocidade nesse caso é menos >> relevante que a quantidade. A regra é bem simples: quanto mais memória >> melhor! >> >> Na FAQ do Squid existe[1] uma discussão muito boa sobre como calcular o >> tamanho do seu cache_dir com base em quanto você tem de memória RAM. >> >> Note que a ordem é diferente do que todos pensam. Você não configura o >> tamanho do cache em disco de acordo com o tamanho do seu disco. Esse é o >> primeiro erro, e o principal fator de fracasso. Você define quanto usar >> de cache_dir de acordo com quanto tem de RAM. É um cálculo delicado que >> envolve quanto de RAM você tem, quanto será usado por MB de cache_dir, >> quanto você quer usar pro cache_mem e quanto seu sistema operacional vai >> consumir. >> >> Se colocar o Thunder na mesma máquina ainda envolve no cálculo quanto de >> memória o thunder vai consumir. E isso vai variar com a sua expectativa >> máxima de threads. >> >> Leia com muita atenção a FAQ do Squid e do Thunder[2] pra tunar isso. >> >> Outro ponto é que quanto mais cache_mem você puder ter, mais vai aliviar >> seu disco, podendo compensar inclusive arquivos pequenos (aqueles que é >> bom evitar). Mas lembre-se que cache_mem não é quanto de memória o >> Lusca/Squid vão usar. É quanto de memória será usado pros Hot Objects. >> >> De qualquer forma se você tiver muita RAM e tunar o cache_mem pra baixo, >> em tese não aproveitando a meória pros Hot Objects, no FreeBSD e graças >> ao UFS_DIRHASH e também ao cache de dados do sistema de arquivo que o >> FreeBSD vai fazer sozinho por padrão (kernel GENERIC), você vai ter >> compensação de I/O de disco com esse cache de memória. Nesse caso, com >> bastante RAM, da até pra fugir desses limites de tamanho de disco, pois >> quanto mais RAM pro FreeBSD, menos TPS consumidos nos seus discos. >> >> Ou seja quanto você puder investir em RAM vai orientar todas as outras >> suas decisões. >> >> Voltando aos discos, tente ter um ou dois discos pro sistema, isolados >> (se for 2, em RAID-1 com gmirror), e os demais discos em RAID-0. Faça >> RAID-0 com Geom Stripe. >> >> Faça RAID-0 com Geom Stripe. >> >> Sei que repeti. É pra dar ênfase ;-) Eu testei muito RAID-0 com >> controladoras típicas no percado tupiniquim, em especial as P4X vendidas >> com servidores HP e PERC vendidas com DELL. O RAID-0 delas não chega nem >> perto em performance do Gstripe. Fuja como o diabo corre da cruz, de >> RAID de BIOS. RAID de BIOS são esses RAID... de BIOS sabe? Que vem na >> placa mãe. Os linuxers chamam de FakeRAID, eu chamo de qualquer RAID que >> o "atacontrol" controle e o FreeBSD reconheça como ar(4). Nem considere >> usar! Você tem Geom Stripe ;-) >> >> RAID-0 por hardware que substituiria o Gstripe só se for com >> controladora LSI Lo
[FUG-BR] Xorg
Pessoal, estou encontrando problemas para iniciar o Xorg no bsd 8 , instado na em uma maquina virtual para testes. (vmware) Tudo se resume no erro abaixo... Alguém pode me ajudar? Obs.: a maquina é um i7 6Gb rodando win7 failed to load module "vmwgfx" (module does not exist, 0) vmware Obrigado. Marcos - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] Regras paras determinados ToS/Diffserv
Pessoal, como posso marcar no PF pra uma determinada regra pacotes com um certo ToS/Diffserver? Tentei encontrar documentacao mas nao consegui encontrar nada a respeito. To usando FreeBSD-8 Obrigado! - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Dicas de Servidores DNS
O BIND está muito seguro mesmo, os problemas que ele ainda enfrenta são questões do protocolo, que todas as soluções também estão sujeitas. Vá de BIND. :) Em 7 de novembro de 2010 11:25, Alexandre Silva Nano escreveu: > Muito obrigado! > > Em 7 de novembro de 2010 04:43, Mario Augusto Mania > escreveu: > > > Cara... o bind esta muito seguro. Passado eh passado! > > > > m3 > > > > Em 7 de novembro de 2010 10:34, Alexandre Silva Nano > > escreveu: > > > Saudações a todos da lista! > > > > > > Vou contar brevemente o meu caso: Pretendo em um futuro muito próximo > > montar > > > meu próprio negócio de co-location, hospedagem de sites e domínios. > > > > > > A minha pergunta é: Estou em dúvida quanto às soluções DNS existentes. > > > > > > Andei pesquisando e vi que o DJBDNS é muito seguro no que se refere à > > > exploits e robustez, e inclusive o desenvolvedor oferece US$1000,00 > para > > > quem conseguir achar uma brecha de segurança. Porém, não achei o DJBDNS > > > amigável (costume de BIND). > > > > > > Vi também o DNSCACHE, mais simples de operar e se dar manutenção, mas > não > > > achei muita coisa relevante (será que procurei certo?). > > > > > > O que os caros amigos acham? > > > > > > Abraços. > > > > > > -- > > > Att, Alexandre Silva Nano > > > - > > > Histórico: http://www.fug.com.br/historico/html/freebsd/ > > > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > > > > > > > > > > > -- > > Atenciosmente > > > > Mario Augusto Mania > > --- > > m3.bsd.ma...@gmail.com > > Cel.: (43) 9938-9629 > > Msn: ma...@oquei.com > > - > > Histórico: http://www.fug.com.br/historico/html/freebsd/ > > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > > > > > > -- > Att, Alexandre Silva Nano > Tels.: (71)3017-5308 / (71)9947-0430 / (71)8710-6422 > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Dicas de Servidores DNS
Muito obrigado! Em 7 de novembro de 2010 04:43, Mario Augusto Mania escreveu: > Cara... o bind esta muito seguro. Passado eh passado! > > m3 > > Em 7 de novembro de 2010 10:34, Alexandre Silva Nano > escreveu: > > Saudações a todos da lista! > > > > Vou contar brevemente o meu caso: Pretendo em um futuro muito próximo > montar > > meu próprio negócio de co-location, hospedagem de sites e domínios. > > > > A minha pergunta é: Estou em dúvida quanto às soluções DNS existentes. > > > > Andei pesquisando e vi que o DJBDNS é muito seguro no que se refere à > > exploits e robustez, e inclusive o desenvolvedor oferece US$1000,00 para > > quem conseguir achar uma brecha de segurança. Porém, não achei o DJBDNS > > amigável (costume de BIND). > > > > Vi também o DNSCACHE, mais simples de operar e se dar manutenção, mas não > > achei muita coisa relevante (será que procurei certo?). > > > > O que os caros amigos acham? > > > > Abraços. > > > > -- > > Att, Alexandre Silva Nano > > - > > Histórico: http://www.fug.com.br/historico/html/freebsd/ > > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > > > > > > -- > Atenciosmente > > Mario Augusto Mania > --- > m3.bsd.ma...@gmail.com > Cel.: (43) 9938-9629 > Msn: ma...@oquei.com > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > -- Att, Alexandre Silva Nano Tels.: (71)3017-5308 / (71)9947-0430 / (71)8710-6422 - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Dicas de Servidores DNS
Cara... o bind esta muito seguro. Passado eh passado! m3 Em 7 de novembro de 2010 10:34, Alexandre Silva Nano escreveu: > Saudações a todos da lista! > > Vou contar brevemente o meu caso: Pretendo em um futuro muito próximo montar > meu próprio negócio de co-location, hospedagem de sites e domínios. > > A minha pergunta é: Estou em dúvida quanto às soluções DNS existentes. > > Andei pesquisando e vi que o DJBDNS é muito seguro no que se refere à > exploits e robustez, e inclusive o desenvolvedor oferece US$1000,00 para > quem conseguir achar uma brecha de segurança. Porém, não achei o DJBDNS > amigável (costume de BIND). > > Vi também o DNSCACHE, mais simples de operar e se dar manutenção, mas não > achei muita coisa relevante (será que procurei certo?). > > O que os caros amigos acham? > > Abraços. > > -- > Att, Alexandre Silva Nano > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > -- Atenciosmente Mario Augusto Mania --- m3.bsd.ma...@gmail.com Cel.: (43) 9938-9629 Msn: ma...@oquei.com - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Problema com ACPI?
Oi Patrick! De fato "shutdown -p now" funciona! Agora, por que o "desligar" do KDE não funciona assim? Acho q vou voltar ao meu belo e leve openbox e fazer um script p/ esse shutdown! Valeu! Zendrael www.zendrael.com.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] Dicas de Servidores DNS
Saudações a todos da lista! Vou contar brevemente o meu caso: Pretendo em um futuro muito próximo montar meu próprio negócio de co-location, hospedagem de sites e domínios. A minha pergunta é: Estou em dúvida quanto às soluções DNS existentes. Andei pesquisando e vi que o DJBDNS é muito seguro no que se refere à exploits e robustez, e inclusive o desenvolvedor oferece US$1000,00 para quem conseguir achar uma brecha de segurança. Porém, não achei o DJBDNS amigável (costume de BIND). Vi também o DNSCACHE, mais simples de operar e se dar manutenção, mas não achei muita coisa relevante (será que procurei certo?). O que os caros amigos acham? Abraços. -- Att, Alexandre Silva Nano - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Harware para Cache
Patrick, e ZFS? > Date: Sun, 7 Nov 2010 03:30:33 -0200 > From: eks...@freebsdbrasil.com.br > To: freebsd@fug.com.br > Subject: Re: [FUG-BR] Harware para Cache > > On 06/11/2010 18:55, sergio wrote: > > Alguém recomenda algum hardware ou solução para cache profissional para > > provedor ? > > Sérgio, solução recomendo fortemente Lusca com Thunder Cache Pro. > > Quanto a hardware depende de muitos fatores. O principal é quantos > usuários você vai pendurar atrás desse proxy. > > O mais importante gargalo a ser evitado é o de I/O de disco. Considere > que de forma geral você tem dois limites em um disco. O mais óbvio, > espaço. O menos, número de operações por segundo (TPS). Um disco > SATA-300 de 7200rpm por exemplo vai suportar de 300 a 420TPS variando de > acordo com as taxas de operações de escrita e leitura. Isso vai resultar > numa taxa de 80MB/s a 120MB/s. > > Em um cache já rodando há alguns dias, as operações de disco são em sua > maioria (~> 75%) de leitura (o restante de escrita). Quanto mais dados > em disco, maior a taxa de operações de leitura. Óbvio. > > Com cerca de 400GB de disco alocado, seu TPS já fica acima de 300. Com > cerca de 550, 600GB provavelmente você vai bater no limite de TPS do > disco. Dessa forma imagine o que acontece se você usar um disco de 1TB > por exemplo, mas com performance SATA2/7200rpm. > > Ou seja discos muito grandes são excelente pra backup. Pra cache vão > gargalar. Então a primeira dica é ficar com discos de 500GB pra SATA2, > discos de 750GB pra SATA3 e acima disso, SAS. Claro que da pra variar um > pouco pra cima, mas já passa do ponto de segurança. > > Outra consideração é ser seletivo no que cachear. Não cachear qualquer > coisa e em especial não cachear arquivos muito pequenos. Arquivos > pequenos vão consumir seus preciosos TPS, e dependendo da taxa de uso > dos discos é mais rápido busca-los na internet do que no disco. > Atenha-se a arquivos acima de 32K. Você pode tunar isso no Lusca e no > Thunder. > > O próximo ponto é a memória. O ideal é que a placa mãe suporte a memória > em sua maior taxa barramento. Mas a velocidade nesse caso é menos > relevante que a quantidade. A regra é bem simples: quanto mais memória > melhor! > > Na FAQ do Squid existe[1] uma discussão muito boa sobre como calcular o > tamanho do seu cache_dir com base em quanto você tem de memória RAM. > > Note que a ordem é diferente do que todos pensam. Você não configura o > tamanho do cache em disco de acordo com o tamanho do seu disco. Esse é o > primeiro erro, e o principal fator de fracasso. Você define quanto usar > de cache_dir de acordo com quanto tem de RAM. É um cálculo delicado que > envolve quanto de RAM você tem, quanto será usado por MB de cache_dir, > quanto você quer usar pro cache_mem e quanto seu sistema operacional vai > consumir. > > Se colocar o Thunder na mesma máquina ainda envolve no cálculo quanto de > memória o thunder vai consumir. E isso vai variar com a sua expectativa > máxima de threads. > > Leia com muita atenção a FAQ do Squid e do Thunder[2] pra tunar isso. > > Outro ponto é que quanto mais cache_mem você puder ter, mais vai aliviar > seu disco, podendo compensar inclusive arquivos pequenos (aqueles que é > bom evitar). Mas lembre-se que cache_mem não é quanto de memória o > Lusca/Squid vão usar. É quanto de memória será usado pros Hot Objects. > > De qualquer forma se você tiver muita RAM e tunar o cache_mem pra baixo, > em tese não aproveitando a meória pros Hot Objects, no FreeBSD e graças > ao UFS_DIRHASH e também ao cache de dados do sistema de arquivo que o > FreeBSD vai fazer sozinho por padrão (kernel GENERIC), você vai ter > compensação de I/O de disco com esse cache de memória. Nesse caso, com > bastante RAM, da até pra fugir desses limites de tamanho de disco, pois > quanto mais RAM pro FreeBSD, menos TPS consumidos nos seus discos. > > Ou seja quanto você puder investir em RAM vai orientar todas as outras > suas decisões. > > Voltando aos discos, tente ter um ou dois discos pro sistema, isolados > (se for 2, em RAID-1 com gmirror), e os demais discos em RAID-0. Faça > RAID-0 com Geom Stripe. > > Faça RAID-0 com Geom Stripe. > > Sei que repeti. É pra dar ênfase ;-) Eu testei muito RAID-0 com > controladoras típicas no percado tupiniquim, em especial as P4X vendidas > com servidores HP e PERC vendidas com DELL. O RAID-0 delas não chega nem > perto em performance do Gstripe. Fuja como o diabo corre da cruz, de > RAID de BIOS. RAID de BIOS são esses RAID... de BIOS sabe? Que vem na > placa mãe. Os linuxers chamam de FakeRAID, eu chamo de qualquer RAID que > o "atacontrol" controle e o FreeBSD reconheça como ar(4). Nem considere > usar! Você tem Geom Stripe ;-) > > RAID-0 por hardware que substituiria o Gstripe só se for com > controladora LSI Logic ou QLogic. Essas podem dar mais performance que o > Gstripe. De todas que tive o prazer de testar, só elas. > > Dê uma l
