Re: [FUG-BR] Duvida Ipfw
Rafael Busetti wrote: > Pessoal to brincando aqui com minha rede interna, pra montar uma > firewallzinha, ai assim, lancei a regra para liberar tudo ... para ir > testando as configs... > > Minha rede está montada assim, a internet se liga em um computador e > esse computador se liga em um hub, e o hub distribui. Ai as máquinas > que estão ligadas no modem não podem enxergar o meu modem, só o > servidor pode, não consegui adicionar essa acl, existe algumas acl's > mais ou menos padrão para deixar uma rede "segura"? Outro problema que > tive, se eu não lanço a 1º acl com any to any, que que eu preciso > liberar para minha internet voltar a funcionar. > Existe o rc.firewall(um script) que fica no /etc, leia o arquivo(e' auto-explicativo). > Agradeço se alguém puder ajudar! > - > 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] Problemas com Routed.
Olá, Estou com problemas com o routed... Tenho um roteador(FreeBSD 6.2 STABLE) usando o "routed" para "fazer as rotas" entre as redes iii.iii.iii.i/24 (rede interna) e eee.eee.eee.e/26 (rede externa), mas ele considera a interna como iii.iii.iii.i/26 , logo não consigo de fora encontrar o ips acima de iii.iii.iii.63 . Qualquer ajuda... agradeço.. Haa, minhas configurações... ---rc.conf- ifconfig_em0="inet iii.iii.iii.1 netmask 255.255.255.0" ifconfig_sk0="inet eee.eee.eee.11 netmask 255.255.255.192" #mrouted_enable="YES" defaultrouter="eee.eee.eee.1" router_enable="YES" router_flags="-s" gateway_enable="YES" router="/sbin/routed" - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Dúvida_-_releases_ e_stables_-_corre ções_de_bugs
On Sun, 09 Apr 2006 21:14:30 -0300, Giovanni P. Tirloni <[EMAIL PROTECTED]> wrote: > > On Sun, April 9, 2006 9:06 pm, Thiago Esteves de Oliveira said: > >> Então se for instalar uma 'Old Release' não se pode fugir das >> atualizações pós instalação (mas para que alguém instalaria uma 4.x >> Release,..., em 2006...nao é)... > Geralmente em sistemas críticos você quer diminuir a quantidades de > mudanças no dia-a-dia para evitar problemas. Minha sugestão é instalar > um -RELEASE e aplicar os patches de segurança periodicamente. > Para isso você pode utilizar a tag RELENG_6_0, no caso do 6.0. > Se for o caso de uma relase mais nova conter mudanças que você ache > interessantes estude bem ela, faça algum projeto piloto, analise as > mudanças em outras áreas que você inicialmente não queria mexer, etc. > > Eu costumava deixar os sistemas em -STABLE mas ultimamente utilizo > apenas > -RELEASE+patches e pulo de release em release. Cada um tem seu jeito ;) > >> ...Então >> aproveitando o assunto sobre atualização...Um sistema >> compilado no próprio 'servidor' (máquina) >> com as opções 'especiais' do gcc para um estilo de >> processador (-march,etc...), será muito mais >> rápido, mais ou menos, existe alguma comparação, >> alguém já fez alguma comparação entre as velocidades de execução, >> tamanho, ..., dos binários >> criados apartir das "compilações especiais"? > À‰ outra coisa que, com o tempo, fui percebendo e comprovando com as > experiências de outras pessoas que não gera nenhum grande benefícios. > Dizem que 1-3% na performance. Não é lá essas coisas, é ? Parece que > o GCC 4.0 consegue otimizar melhor certas coisas mas de cabeça não > lembro muita coisa. > > Também deixei de encher meu make.conf com flags de otimização para > CPUs depois que um servidor pifou e, na emergência, precisei trocar o > sistema de Intel para AMD.. e havia compilado com as flags especificas > para P3. O sistema não bootou, assunto encerrado. Se houver algum ganho > de 15-30% que me interesse algum dia posso até estudar a possibilidade > novamente. Por enquanto prefiro algo mais "certo" :) > > Felicidades, > Giovanni, Pergunta... Mas especificando o -march do gcc as funções de CPU como 3dNow da AMD e muitas outras que não lembro seriam utilizadas pelo compilador para compilar o código com mais rapidez ou para gerar um 'binário' capaz de trabalhar com essas funções de cpu? Abraço... -- === Thiago Esteves de Oliveira < === ___ freebsd mailing list freebsd@fug.com.br http://lists.fug.com.br/listinfo.cgi/freebsd-fug.com.br
Re: [FUG-BR] Dúvida_-_releases_ e_stables_-_corre ções_de_bugs
On Sun, 09 Apr 2006 19:59:09 -0300, Patrick Tracanelli <[EMAIL PROTECTED]> wrote: > Thiago Esteves de Oliveira wrote: >>Olá pessoal, >> >>Estava olhanda na mensagem " >> ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-06:13.sendmail.asc >> " do campo "Security Advisories" do site www.freebsd.org e uma dúvida >> (não >> tem nada a ver com a mensagem) apareceu... >> -- >>Bom, lendo como corrigir o bug...ele pede para que seja feita uma >> atualização para uma das versões stables: 4.11, 5, 6... >> >>"ok, sei que não é preciso atualizar o sistema inteiro para corrigir >> um >> bug de um software", mas gostaria de saber se os isos (5.4-Release e >> 6-Release) disponíveis para download no site, já estão com os os mais >> recentes bugs corrigidos? >> >>Abraço... >> > > Thiago, > > Nao. > As versoes -RELEASE do FreeBSD tem como objetivo primario ser sistemas > pra distribuicao em massa. Sao versoes datadas, e como tal, nao tem > problemas recentes corrigidos. Esse ciclo dura em media 4 meses (a cada > novo release) entao na pratica voce pode ter um sistema recem instalado > com 4 meses de bugs nao corrigidos. Felizmente os bugs no FreeBSD sao > pouco frequentes, frente `a media de outros sistemas, abertos ou > proprietarios. > > Por isso a discriminacao de SAs em http://www.freebsd.org/security/ > tende a ser organizada da forma mais cronologica o possivel, mencionando > o schedule das ultimas versoes -RELEASE e quais SA os afectam. > > Por isso um dos procedimentos obrigatorios de um sysadmin FreeBSD > responsavel e atualizar seu sistema recem-instalado antes de coloca-lo > em producao. Como atualizar voce pode entender passar pra -STABLE, > passar pra algum Security Branch (os -RELEASE-pX) ou utilizar o > freebsd-update pra atualizacao binaria. > > Salvo raras excecoes quando o conjunto de falhas incluem problemas da > base e da userland, em especial aplicacoes de terceiros contribuidas, e > estes problemas sao extremamente graves, ao ponto de comprometer todo o > -RELEASE e nao fazer sentido o -RELEASE em questao continuar existindo > dada a seriedade dos problemas, ai sim sao lancados novos releases que > antecipam o ciclo de vida das versoes do sistema, sao os chamados > FreeBSD de versao Minor Number Level 2, como 5.2.1 da vida, etc. Nesse > caso o Minor Number deixa de existir e so passa a existir o Minor Number > Level 2 disponivel pra download. Mas isso nao e comum, e em teoria nao > deve acontecer. Quando acontece o ciclo periodico de versoes passa a ser > contado a partir do ultimo Minor Number Level 2. > Patrick, Então se for instalar uma 'Old Release' não se pode fugir das atualizações pós instalação (mas para que alguém instalaria uma 4.x Release,..., em 2006...nao é)... ...Então aproveitando o assunto sobre atualização...Um sistema compilado no próprio 'servidor' (máquina) com as opções 'especiais' do gcc para um estilo de processador (-march, etc...), será muito mais rápido, mais ou menos, existe alguma comparação, alguém já fez alguma comparação entre as velocidades de execução, tamanho, ..., dos binários criados apartir das "compilações especiais"? Abraço === Thiago Esteves de Oliveira < === -- === Thiago Esteves de Oliveira < === ___ freebsd mailing list freebsd@fug.com.br http://lists.fug.com.br/listinfo.cgi/freebsd-fug.com.br
[FUG-BR] Dúvida - releases e stables - correç ões de bugs
Olá pessoal, Estava olhanda na mensagem " ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-06:13.sendmail.asc " do campo "Security Advisories" do site www.freebsd.org e uma dúvida (não tem nada a ver com a mensagem) apareceu... -- Bom, lendo como corrigir o bug...ele pede para que seja feita uma atualização para uma das versões stables: 4.11, 5, 6... "ok, sei que não é preciso atualizar o sistema inteiro para corrigir um bug de um software", mas gostaria de saber se os isos (5.4-Release e 6-Release) disponíveis para download no site, já estão com os os mais recentes bugs corrigidos? Abraço... -- =============== Thiago Esteves de Oliveira < === ___ freebsd mailing list freebsd@fug.com.br http://lists.fug.com.br/listinfo.cgi/freebsd-fug.com.br
Re: [FUG-BR]__Dúvida__-_N O_FOOF_HACK
On Sat, 08 Apr 2006 18:44:49 -0300, Patrick Tracanelli
<[EMAIL PROTECTED]> wrote:
> Thiago Esteves de Oliveira wrote:
>> On Sat, 08 Apr 2006 17:45:55 -0300, Rainer Alves
>> <[EMAIL PROTECTED]>
>> wrote:
>>
>>
>>> Thiago Esteves de Oliveira wrote:
>>>
>>>> Li o NOTES/NO_FOOF_HACK, ok, mas gostaria de saber se a opção
>>>> NO_FOOF_HACK deve ser usada
>>>> apenas em "i586(s)" como dito no NOTES, pois já vi servidores
>>>> "i686(s)",
>>>> com esta opção abilitada na
>>>> compilação do kernel.
>>>
>>> A primeira edição do Pentium (de séculos atrás) tinha um bug que
>>> causava
>>> o travamento da CPU se ela recebesse uma sequência de instruções que
>>> iniciava com os byte codes 'F0 0F' (em hexadecimal, daí o nome).
>>> Esse 'NO_F00F_HACK' nada mais é do que uma proteção do kernel, que gera
>>> um erro de instrução ilegal ao detectá-las.
>>> A opção só faz sentido se você usar o Pentium 1 (i586), habilitá-la em
>>> qualquer outro kernel é desperdício já que a Intel corrigiu o bug no
>>> design dos Pentiums seguintes.
>>>
>>> --
>>> Rainer Alves
>
> Na verdade, e' exatamente o contrario hehe.
>
> O F00F_HACK e uma serie de codigos pra evitar o problema muito bem
> explicado pelo Rainer, a principal correcao e o codigo a seguir
>
> #if defined(I586_CPU) && !defined(NO_F00F_HACK)
> if (i == -2) {
> /*
> * The f00f hack workaround has
> triggered, so
> * treat the fault as an illegal
> instruction
> * (T_PRIVINFLT) instead of a page
> fault.
> */
> type = frame.tf_trapno = T_PRIVINFLT;
>
> /* Proceed as in that case. */
> ucode = type;
> i = SIGILL;
> break;
> }
> #endif
>
> Que fica no sys/i386/i386/trap.c.
>
> Portanto, note que o F00F_HACK *ja existe* em toda e qualquer situacao
> que voce tenha I586 no kernel. Nao e' necessario adiciona-lo para te-lo.
> A opcao do NOTES faz o contrario, ela OMITE o F00F_HACK, por isso
> chama-se "NO_F00F_HACK", "sem F0 0F hack" que ja existe por padrao,
> tendo I586 no kernel.
>
> Portanto a opcao so deve ser usada se voce *NAO* usar I586 (por exemplo,
> mantem apenas classe de CPU I686 no kernel) ou se voce mantem seu kernel
> apto a processar instrucoes de classe i586 mas tem certeza que jamais
> serao processadores Pentium nessa classe, por exemplo, AMD K6 2, CYRIX e
> afins, que sao 586 mas nao sofrem desse bug (bug exclusivo dos Pentium).
>
> Note que na primeira situacao (nao manter i586 no kernel) colocar a
> opcao NO_F00F_HACK e' redundante (note o && do if defined).
>
>
Ok.
Então se não estiver usando um I586(ONLY PENTIUM)
Use "NO_FOOF_HACK" = 'SEU PROCESSADOR NÃO PRECISA'
he, he, he, he
Abraço...
--
===
Thiago Esteves de Oliveira <
===
___
freebsd mailing list
freebsd@fug.com.br
http://lists.fug.com.br/listinfo.cgi/freebsd-fug.com.br
Re: [FUG-BR] Dúvida - NO_FOOF_H ACK
On Sat, 08 Apr 2006 17:45:55 -0300, Rainer Alves <[EMAIL PROTECTED]> wrote: > Thiago Esteves de Oliveira wrote: >> Li o NOTES/NO_FOOF_HACK, ok, mas gostaria de saber se a opção >> NO_FOOF_HACK deve ser usada >> apenas em "i586(s)" como dito no NOTES, pois já vi servidores "i686(s)", >> com esta opção abilitada na >> compilação do kernel. > > A primeira edição do Pentium (de séculos atrás) tinha um bug que causava > o travamento da CPU se ela recebesse uma sequência de instruções que > iniciava com os byte codes 'F0 0F' (em hexadecimal, daí o nome). > Esse 'NO_F00F_HACK' nada mais é do que uma proteção do kernel, que gera > um erro de instrução ilegal ao detectá-las. > A opção só faz sentido se você usar o Pentium 1 (i586), habilitá-la em > qualquer outro kernel é desperdício já que a Intel corrigiu o bug no > design dos Pentiums seguintes. > > -- > Rainer Alves > ___ > freebsd mailing list > freebsd@fug.com.br > http://lists.fug.com.br/listinfo.cgi/freebsd-fug.com.br Obrigado pela explicação amigo, bom fim de semana... -- === Thiago Esteves de Oliveira < === ___ freebsd mailing list freebsd@fug.com.br http://lists.fug.com.br/listinfo.cgi/freebsd-fug.com.br
[FUG-BR] Dúvida - NO_FOOF_HACK
Olá pessoal, Li o NOTES/NO_FOOF_HACK, ok, mas gostaria de saber se a opção NO_FOOF_HACK deve ser usada apenas em "i586(s)" como dito no NOTES, pois já vi servidores "i686(s)", com esta opção abilitada na compilação do kernel. Abraço. -- =========== Thiago Esteves de Oliveira < === ___ freebsd mailing list freebsd@fug.com.br http://lists.fug.com.br/listinfo.cgi/freebsd-fug.com.br
