Re: [FUG-BR] [OT] Existe algum BSD para este hardware
Caro amigo, >> [FUG-BR] [OT] Existe algum BSD para este hardwareBoa tarde lista, >> Gostaria de saber se para esse hardware terei que seguir o mesmo caminho? >> Ou >> o FreeBSD 7 podera ser customizado para esse hardware? >> http://www.compulab.co.il/iglx/html/iglx-cm-datasheet.htm Sobre a sua pergunta, deve rodar sem problemas pois de acordo com as especificações do fabricante, ele é um x86. Os periféricos também não devem apresentar problemas pois devem ser compatíveis (pelo menos vi chips Realteks... =P). Uma curiosidade, como você conseguiu um destes ?! Abraços, -- Davi Vercillo Carneiro Garcia http://davivercillo.blogspot.com/ Universidade Federal do Rio de Janeiro Departamento de Ciência da Computação DCC-IM/UFRJ - http://www.dcc.ufrj.br Grupo de Usuários GNU/Linux da UFRJ (GUL-UFRJ) http://www.dcc.ufrj.br/~gul Linux User: #388711 http://counter.li.org/ "A democracia muitas vezes significa o poder nas mãos de uma maioria incompetente." - Bernard Shaw "Good things come to those who... wait." - Debian Project "Theory is when you know something, but it doesn't work. Practice is when something works, but you don't know why. Programmers combine theory and practice: Nothing works and they don't know why." - Anon - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [OT] Existe algum BSD para este hardware
Qualquer SO i386 deve rodar nisso. Até Windows. Abraço, 2008/12/16 WIlson Mendes > [FUG-BR] [OT] Existe algum BSD para este hardwareBoa tarde lista, > Gostaria de saber se para esse hardware terei que seguir o mesmo caminho? > Ou > o FreeBSD 7 podera ser customizado para esse hardware? > http://www.compulab.co.il/iglx/html/iglx-cm-datasheet.htm > > Descricao > CPU:AMD Geode LX800 > Memory:256mb DDR > Integrated: 60GB HDD > VGA Display up to 1920x1440 > Dual Ethernet 100Mbps > > Obs: Ubutun e o Opensuse rodaram sem problemas > > Obrigado a todos! > > > > > > > > > > > > > > 2008/11/25 joao jamaicabsd > > > Boa tarde. > > Agora apareceu uma luz no fim do túnel. Pode me dar algum contato que uma > > pessoa ou empresa que desenvolva ou saiba me dar mais informações sobre > > isso? > > Obrigado pela exelente informação. > > > > > > > > > > > > 2008/11/24 Patrick Tracanelli > > > > > joao jamaicabsd escreveu: > > > > Cristina, sei que existe um Micro-Linux para este hardware, mas eu > > > gostaria > > > > de instalar um Sistema Operacional que fosse da baseado em BSD, pois > > > estou > > > > vendo a galera festejando aí por ser certificado, e tem mesmo que > > > > festejar!!! Rsss. Então está aí uma oportunidade de estudar mais > ainda > > um > > > > BSD. Talvez só o Kernel, quem sabe. > > > > > > > > O processador é um LPC2468FBD208 da empresa NXP; > > > > Memória: 512kB de Flash interna; > > > > 96kB de RAM interna; > > > > > > > > Rede: Ethernet, MAC; > > > > > > > > Opera até 72MHz; > > > > > > > > 32 bits > > > > > > > > 4 chips select; > > > > > > > > 2 MB para instalar o SO. > > > > > > > > Ele rodará uma aplicação em LUA, mas pode ser em C. > > > > > > > > Bom find. > > > > > > NetBSD roda em alguns NXP mas nesse só uCLinux. Se a intenção é estudar > > > é uma oportunidade de portar, mas pronto só uCLinux, inclusive com > > > development kit pra esse lx. > > > > > > -- > > > 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 > > > > > > > > > > > -- > > E-mail: jamaica...@gmail.com > > Aux Suporte de Sistemas (UNISUL) > > E-mail: joao.may...@unisul.br > > MSN: joaomayk...@hotmail.com > > Cel: (48) 9144 2326 > > - > > 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 > -- Eduardo Alvarenga - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Placa X100P não funciona
Nesse caso, poderia me passar suas configurações amigo? []'s Vinicius Campos Maia 2008/12/16 renato martins > deve ser alguma conf pq eu uso em casa uma modem clone e ja usei uma da > x100p da atcom e funcionou as duas normal > > 2008/12/16 Vinicius Maia > > > Boa tarde pessoal, > > > > Comprei uma placa X100P para usar minha linha comum em conjunto com minha > > linha VoIP no meu Asterisk, porém tive a surpresa quando instalei. A > placa > > X100P simplesmente não funciona no BSD. > > > > Seguem as informações: > > > > # Esse kernel é uma recompilação do GENERIC sem nenhuma alteração. > > [r...@supertramp ~]# uname -a > > FreeBSD supertramp.vcmtech.local 7.0-RELEASE-p5 FreeBSD 7.0-RELEASE-p5 > #0: > > Sat Nov 22 16:57:46 BRST 2008 > > r...@supertramp.vcmtech.local:/usr/obj/usr/src/sys/SUPERTRAMP i386 > > > > # Essa mensagem se repete algumas vezes no boot da máquina. > > [r...@supertramp ~]# dmesg > > Zapata Telephony Interface Registered on major 196 > > Echo Canceller: MG2 > > ZapTel device: vendor=1057 device=5608 subvendor=1055 > > wcfxo0: port 0xc800-0xc8ff mem 0xff9ff000-0xff9f irq > > 22 > > at device 1.0 on pci5 > > ZapTel Attach for wcfxo0: deviceID : 0x1057 > > wcfxo0: [FILTER] > > Failed to initailize DAA, giving up... > > Freed a Wildcard > > ZapTel detach! > > We failed: 5 > > device_attach: wcfxo0 attach returned 5 > > > > [r...@supertramp ~]# /usr/local/etc/rc.d/zaptel start > > zaptelKeyword: [fxsks], Value: [1] > > Keyword: [loadzone], Value: [br] > > Keyword: [defaultzone], Value: [br] > > ZT_CHANCONFIG failed on channel 1: Device not configured (6) > > > > [r...@supertramp ~]# less /usr/local/etc/zaptel.conf > > # > > # Zaptel Configuration File > > # > > # This file is parsed by the Zaptel Configurator, ztcfg > > # > > fxsks=1 > > # > > loadzone=br > > defaultzone=br > > > > [r...@supertramp ~]# less /usr/local/etc/asterisk/zapata.conf > > [channels] > > context=default > > signalling=fxs_ks > > group=1 > > channel => 1 > > > > Muito obrigado pela ajuda pessoal. > > > > []´s > > > > Vinicius Campos Maia > > - > > 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] Novidades no FreeBSD 8.0
On Tue, Dec 16, 2008 at 4:32 PM, Nenhum_de_Nos wrote: > > On Mon, December 15, 2008 10:18 am, Renato Botelho wrote: >> 2008/12/13 Joao Rocha Braga Filho : >>> 2008/12/13 Gustavo De Nardin : 2008/12/13 Davi Vercillo C. Garcia (ダヴィ) : > Pessoal, > > Qual a data prevista para o lançamento do FreeBSD 8 ? De http://www.freebsd.org/releng/: --- Upcoming Release Schedule NOTE: Release dates are approximate and may be subject to schedule slippage. DateEvent Information December 2008 FreeBSD 7.1 February 2009 FreeBSD 7.2 >>> >>> O lançamento do 7.2 está muito perto do 7.1. Será que já começaram >>> a >>> preparar o lançamento do 7.2? >> >> Na verdade o 7.2 vai ser alterado, o que aconteceu foi que o 7.1 demorou >> demais pra chegar no RC1 e isso atrasou o lançamento. >> >> O Ken Smith mandou um email na developers falando sobre isso, disse que >> do jeito que está hoje não está funcionando direito, então vai tentar >> fazer >> algumas mudanças no processo de lançamento de versão. > > tens idéia das mudanças ? > > vi nas listas @freebsd.org algumas threads sobre mudar isso, mas era > sempre usuário falando e não gente de dentro. Não posso dizer ao certo ainda, mas posto aqui quando tiver algo mais concreto. O que precisa mudar são os ports por exemplo, os pkgs estão prontos desde setembro, ou seja, estão "velhos" pra quando o 7.1 sair. Acho que isso vai mudar, rolando o freeze do ports apenas quando for sair no RC1 e não mais no BETA1. Uma coisa que é certa, é que o Ken Smith vai mandar emails semanalmente pras listas abertas dando um status de como as coisas estão, uma coisa que eu sinto falta hoje. > eu gostaria muito de ter o freebsd com numeração sequencial, como o open. > eles estão ativos e no 4.4. nós já vamos no 7.1. hehehe jajá teremos o > freebsd 44.1 ;) Eu particularmente me importo mais em ter uma versão funcionando, o número dela não me faz muita diferença. A idéia de se ter as major version (7.x, 8.x, 9.x) é a possibilidade de marcar mudanças muito grandes no sistema, como foi o caso do ULE no 7.0, e como vai ser o vimage no 8.0 por exemplo. > vai atrasar o 8 tb, sabes dizer ? Isso ainda é incerto. -- Renato Botelho - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Placa X100P não funciona
deve ser alguma conf pq eu uso em casa uma modem clone e ja usei uma da x100p da atcom e funcionou as duas normal 2008/12/16 Vinicius Maia > Boa tarde pessoal, > > Comprei uma placa X100P para usar minha linha comum em conjunto com minha > linha VoIP no meu Asterisk, porém tive a surpresa quando instalei. A placa > X100P simplesmente não funciona no BSD. > > Seguem as informações: > > # Esse kernel é uma recompilação do GENERIC sem nenhuma alteração. > [r...@supertramp ~]# uname -a > FreeBSD supertramp.vcmtech.local 7.0-RELEASE-p5 FreeBSD 7.0-RELEASE-p5 #0: > Sat Nov 22 16:57:46 BRST 2008 > r...@supertramp.vcmtech.local:/usr/obj/usr/src/sys/SUPERTRAMP i386 > > # Essa mensagem se repete algumas vezes no boot da máquina. > [r...@supertramp ~]# dmesg > Zapata Telephony Interface Registered on major 196 > Echo Canceller: MG2 > ZapTel device: vendor=1057 device=5608 subvendor=1055 > wcfxo0: port 0xc800-0xc8ff mem 0xff9ff000-0xff9f irq > 22 > at device 1.0 on pci5 > ZapTel Attach for wcfxo0: deviceID : 0x1057 > wcfxo0: [FILTER] > Failed to initailize DAA, giving up... > Freed a Wildcard > ZapTel detach! > We failed: 5 > device_attach: wcfxo0 attach returned 5 > > [r...@supertramp ~]# /usr/local/etc/rc.d/zaptel start > zaptelKeyword: [fxsks], Value: [1] > Keyword: [loadzone], Value: [br] > Keyword: [defaultzone], Value: [br] > ZT_CHANCONFIG failed on channel 1: Device not configured (6) > > [r...@supertramp ~]# less /usr/local/etc/zaptel.conf > # > # Zaptel Configuration File > # > # This file is parsed by the Zaptel Configurator, ztcfg > # > fxsks=1 > # > loadzone=br > defaultzone=br > > [r...@supertramp ~]# less /usr/local/etc/asterisk/zapata.conf > [channels] > context=default > signalling=fxs_ks > group=1 > channel => 1 > > Muito obrigado pela ajuda pessoal. > > []´s > > Vinicius Campos Maia > - > 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] [OT] Existe algum BSD para este hardware
[FUG-BR] [OT] Existe algum BSD para este hardwareBoa tarde lista, Gostaria de saber se para esse hardware terei que seguir o mesmo caminho? Ou o FreeBSD 7 podera ser customizado para esse hardware? http://www.compulab.co.il/iglx/html/iglx-cm-datasheet.htm Descricao CPU:AMD Geode LX800 Memory:256mb DDR Integrated: 60GB HDD VGA Display up to 1920x1440 Dual Ethernet 100Mbps Obs: Ubutun e o Opensuse rodaram sem problemas Obrigado a todos! 2008/11/25 joao jamaicabsd > Boa tarde. > Agora apareceu uma luz no fim do túnel. Pode me dar algum contato que uma > pessoa ou empresa que desenvolva ou saiba me dar mais informações sobre > isso? > Obrigado pela exelente informação. > > > > > > 2008/11/24 Patrick Tracanelli > > > joao jamaicabsd escreveu: > > > Cristina, sei que existe um Micro-Linux para este hardware, mas eu > > gostaria > > > de instalar um Sistema Operacional que fosse da baseado em BSD, pois > > estou > > > vendo a galera festejando aí por ser certificado, e tem mesmo que > > > festejar!!! Rsss. Então está aí uma oportunidade de estudar mais ainda > um > > > BSD. Talvez só o Kernel, quem sabe. > > > > > > O processador é um LPC2468FBD208 da empresa NXP; > > > Memória: 512kB de Flash interna; > > > 96kB de RAM interna; > > > > > > Rede: Ethernet, MAC; > > > > > > Opera até 72MHz; > > > > > > 32 bits > > > > > > 4 chips select; > > > > > > 2 MB para instalar o SO. > > > > > > Ele rodará uma aplicação em LUA, mas pode ser em C. > > > > > > Bom find. > > > > NetBSD roda em alguns NXP mas nesse só uCLinux. Se a intenção é estudar > > é uma oportunidade de portar, mas pronto só uCLinux, inclusive com > > development kit pra esse lx. > > > > -- > > 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 > > > > > > -- > E-mail: jamaica...@gmail.com > Aux Suporte de Sistemas (UNISUL) > E-mail: joao.may...@unisul.br > MSN: joaomayk...@hotmail.com > Cel: (48) 9144 2326 > - > 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] Placa X100P não funciona
Boa tarde pessoal, Comprei uma placa X100P para usar minha linha comum em conjunto com minha linha VoIP no meu Asterisk, porém tive a surpresa quando instalei. A placa X100P simplesmente não funciona no BSD. Seguem as informações: # Esse kernel é uma recompilação do GENERIC sem nenhuma alteração. [r...@supertramp ~]# uname -a FreeBSD supertramp.vcmtech.local 7.0-RELEASE-p5 FreeBSD 7.0-RELEASE-p5 #0: Sat Nov 22 16:57:46 BRST 2008 r...@supertramp.vcmtech.local:/usr/obj/usr/src/sys/SUPERTRAMP i386 # Essa mensagem se repete algumas vezes no boot da máquina. [r...@supertramp ~]# dmesg Zapata Telephony Interface Registered on major 196 Echo Canceller: MG2 ZapTel device: vendor=1057 device=5608 subvendor=1055 wcfxo0: port 0xc800-0xc8ff mem 0xff9ff000-0xff9f irq 22 at device 1.0 on pci5 ZapTel Attach for wcfxo0: deviceID : 0x1057 wcfxo0: [FILTER] Failed to initailize DAA, giving up... Freed a Wildcard ZapTel detach! We failed: 5 device_attach: wcfxo0 attach returned 5 [r...@supertramp ~]# /usr/local/etc/rc.d/zaptel start zaptelKeyword: [fxsks], Value: [1] Keyword: [loadzone], Value: [br] Keyword: [defaultzone], Value: [br] ZT_CHANCONFIG failed on channel 1: Device not configured (6) [r...@supertramp ~]# less /usr/local/etc/zaptel.conf # # Zaptel Configuration File # # This file is parsed by the Zaptel Configurator, ztcfg # fxsks=1 # loadzone=br defaultzone=br [r...@supertramp ~]# less /usr/local/etc/asterisk/zapata.conf [channels] context=default signalling=fxs_ks group=1 channel => 1 Muito obrigado pela ajuda pessoal. []´s Vinicius Campos Maia - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Novidades no FreeBSD 8.0
On Mon, December 15, 2008 10:18 am, Renato Botelho wrote: > 2008/12/13 Joao Rocha Braga Filho : >> 2008/12/13 Gustavo De Nardin : >>> 2008/12/13 Davi Vercillo C. Garcia (ãã´ã£) >>> : Pessoal, Qual a data prevista para o lançamento do FreeBSD 8 ? >>> >>> De http://www.freebsd.org/releng/: >>> >>> --- >>> Upcoming Release Schedule >>> >>> NOTE: Release dates are approximate and may be subject to schedule >>> slippage. >>> DateEvent Information >>> December 2008 FreeBSD 7.1 >>> February 2009 FreeBSD 7.2 >> >> O lançamento do 7.2 está muito perto do 7.1. Será que já começaram >> a >> preparar o lançamento do 7.2? > > Na verdade o 7.2 vai ser alterado, o que aconteceu foi que o 7.1 demorou > demais pra chegar no RC1 e isso atrasou o lançamento. > > O Ken Smith mandou um email na developers falando sobre isso, disse que > do jeito que está hoje não está funcionando direito, então vai tentar > fazer > algumas mudanças no processo de lançamento de versão. tens idéia das mudanças ? vi nas listas @freebsd.org algumas threads sobre mudar isso, mas era sempre usuário falando e não gente de dentro. eu gostaria muito de ter o freebsd com numeração sequencial, como o open. eles estão ativos e no 4.4. nós já vamos no 7.1. hehehe jajá teremos o freebsd 44.1 ;) vai atrasar o 8 tb, sabes dizer ? matheus -- We will call you cygnus, The God of balance you shall be - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] RES: RES: bloquear https com squid
Você pode bloquear o acesso direto á porta 443 no seu firewall e obrigar a todos usarem o squid manualmente no navegador para HTTPS, seja via Police(se for uma rede com AD) ou via script de configuração automática. Conforme já foi dito, o Proxy transparente não aceita HTTPS porque isto seria um ataque 'man in the middle', no caso o squid interferindo na conexão HTTPS, autenticada e autorizada fim a fim. Na verdade o rdr por si só não aceita nem http, você tem que ir no squid e falar que ele está rodando como transparente(HTTP port 3128 transparent), para aí sim funcionar 100%. E tomar cuidado com programas que não tratam isto corretamente, como os famosos aplicativos da Caixa econômica(conectividade social e outros). > -Mensagem original- > De: freebsd-boun...@fug.com.br [mailto:freebsd-boun...@fug.com.br] Em > nome de Renato Botelho > Enviada em: terça-feira, 16 de dezembro de 2008 14:23 > Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) > Assunto: Re: [FUG-BR] RES: bloquear https com squid > > 2008/12/16 Ricardo Augusto de Souza : > > Renato, > > > > eu utilizo proxy transparant sim e o https funciona na boa. > > Porem eu nao redireciono a porta 443. > > > > Veja as regras: > > > > # squid trasparente > > no rdr on $int_if inet proto tcp from $sem_proxy to any port 80 > > rdr pass on $int_if inet proto tcp from $lan to any port 80 -> > $int_if port 128 > > > > Entao é isso: se utilizar transparent nao consigo bloquear sites > https? > > Exato, pode fazer o teste, o transparente não consegue bloquear > https, é impossível por conta da implementação. > > -- > Renato Botelho > - > 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] RES: bloquear https com squid
2008/12/16 Ricardo Augusto de Souza : > Renato, > > eu utilizo proxy transparant sim e o https funciona na boa. > Porem eu nao redireciono a porta 443. > > Veja as regras: > > # squid trasparente > no rdr on $int_if inet proto tcp from $sem_proxy to any port 80 > rdr pass on $int_if inet proto tcp from $lan to any port 80 -> $int_if port > 128 > > Entao é isso: se utilizar transparent nao consigo bloquear sites https? Exato, pode fazer o teste, o transparente não consegue bloquear https, é impossível por conta da implementação. -- Renato Botelho - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] RES: bloquear https com squid
Renato, eu utilizo proxy transparant sim e o https funciona na boa. Porem eu nao redireciono a porta 443. Veja as regras: # squid trasparente no rdr on $int_if inet proto tcp from $sem_proxy to any port 80 rdr pass on $int_if inet proto tcp from $lan to any port 80 -> $int_if port 128 Entao é isso: se utilizar transparent nao consigo bloquear sites https? -Mensagem original- De: freebsd-boun...@fug.com.br [mailto:freebsd-boun...@fug.com.br] Em nome de Leandro Keffer Enviada em: terça-feira, 16 de dezembro de 2008 12:26 Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) Assunto: Re: [FUG-BR] bloquear https com squid Axo que o erro pode estar no firewall, vc esta direcionando a porta 443 ? Pois tanto no autenticado como no transparente o bloqueio funciona 2008/12/16 Renato Botelho > On Tue, Dec 16, 2008 at 12:49 PM, Ricardo Augusto de Souza > wrote: > > Ola, > > eu utilizo a forma abaixo para bloquear alguns domínios: > > > > acl bad_sites dstdomain "/etc/squid/bad_sites.txt" > > > > http_access deny bad_sites > > > > > > Porém os usuarios conseguem acessar os sites via https. > > > > Como vcs bloqueiam sites ( http e https ) ? > > O que deve estar acontecendo é que você usa proxy transparente, > correto? > > Se for isso, não existe maneira pra bloquear https, agora se você usa > autenticado, então com essas regras ele deveria bloquear os dois. > > -- > Renato Botelho > - > 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] bloquear https com squid
2008/12/16 Leandro Keffer : > Axo que o erro pode estar no firewall, vc esta direcionando a porta 443 ? > Pois tanto no autenticado como no transparente o bloqueio funciona Funciona https no transparente? Essa eu não tava sabendo, tem algum link? alguma coisa sobre o assunto? Esse sempre foi o grande problema do squid transparente, IMHO. Como não monto um proxy há alguns anos devo ter perdido essa feature pelo caminho. -- Renato Botelho - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Apache22+php5 - mod_php ou fastcgi ?
E ai Patrick, É vou fazer isso mesmo. php+mysql vou usar o apache+dso, num ip/porta e vou por o lighttpd num jail pq preciso que roda na mesma porta 80, pode ser outro dominio tipo www2, mas nao da pra ser outra porta, pq muitos lugares so permitem acesso na porta 80.. E esse mode rewrite deve consumir uma instancia do apache se ele fizer tipo o "bounce" do bsd.., acho que fica melhor o request chegar direto no lighttpd. Fiz uns testes com o ab, mas sempre da um erro escroto... server64# ab -q -c 5 -n 500 http://74.xxx.144.114/teste.php This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking 74.86.144.114 (be patient)...Send request failed! Send request failed! Send request failed! apr_socket_recv: Connection reset by peer (54) Total of 6 requests completed se rodo so com uma conexao tambem da erro server64# ab -q -c 1 -n 500 http://74.xxx.144.114/teste.php This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking 74.86.144.114 (be patient)...apr_socket_recv: Connection reset by peer (54) eheheh oganza bizaza isso. []'s 2008/12/16 Patrick Tracanelli : > Leonardo Augusto escreveu: >> Ola Patrick.. >> >> Pois é... tudo que voce disse faz sentido.. >> A minha duvida entre os dois modos de operacao se deu no seguinte sentido.. > > Ola Leonardo, > >> >> apache+php via fastcgi: >> --- >> pelo que entendi, e quando rodei nessa configuracao eu vi, que ficam >> varios php-cgi startados.. > > Perfeito, na verdade um php-cgi para cada instância simultânea que > chegou a acontecer. > >> aí quando chega um request que lida com php, o apache comunica direto >> com um desses > > Exato, um monte de syscall passando o arquivo de uma aplicacão pra outra > via socket local. > >> processos cgi que ja estao rodando, via o fastcgi.. >> Li que isso teria vantagens quando alem de php o site trata muito >> arquivo estatico, o que seria > > Na verdade não da pra ter vantagem tecnicamente. Ao inves de termos uma > aplicacao que ja sabe como processar, associando a extensao a um handler > interno que sabe o que fazer, temos na verdade uma aplicacao que associa > a extensao a um handler que nao sabe o que fazer so sabe que tem que > passar pra um socket local, e esperar a resposta pronta. Nesse caso o > trabalho do Apache eh mais leve simplesmente porque ele delega o > trabalho pesado ao CGI. Isso gera várias syscalls adicionais, e > consequentemente overhead adicional. > > Sobre estático VS dinamico da na mesma visto que a associacão de tipos é > por extensão em ambos os casos. Quando se fala de servir estático a > comparação deve ser Apache VS LightHTTP não Apache+PHP-FCGI VS > Apache+PHP-DSO > >> vantagem pois o apache nao teria que carrega o modphp a cada fork.. > > Então, funciona assim. Se tem que haver o fork de um novo child process > sim, todos os modulos DSO sao carregados a cada fork. Sem execao. Isso > inclui o modulo fastcgi do PHP rodando em modo fcgi. Nao faz diferenca. > > A questão é que se for fast-cgi temos ainda outra questão, além dos fork > do apache tem ainda o fork de novos php-cgi. O Apache funciona assim, > quando vc inicia ele inicia StartServers instancias, nesse caso cada um > dlees ja tem o PHP em DSO carregado. Depois de StartServer+1 ele vai > carregar MinSpareServers de uma vez, e eles teão o PHP em DSO. > > Porém se você tem o PHP em FCGI os StartServers vão chamar o modulo que > joga as requisicoes pro fastcgi, que joga sua vez pro spawn-fcgi que por > sua vez iniciam o php-cgi. Isso acontece para cada vez que uma nova > instancia httpd for iniciar que consuma php via fastcgi. > >> tudo bem.. mas até ai poderiamos deixar como vc disse rodando pelo >> menos 512 processos do >> apache com dso e esse delay no fork nao seria problema correto ? > > Correto, é possível, mas não fica acontecendo fork todo o tempo, so > quando ha mais requisicoes simultaneas do que novos processos iniciados. > >> >> apache+php via dso >> >> pois é, nesse caso o gargalo seria se ouvessem muitos forks atrelados >> ao grande numero de hits.. >> até ai tambem se deixar uma grande quantidade de processos sempre >> startados do apache acho >> que nao deve ser problema.. >> >> Essa minha duvida surgiu em funcao de um servico que vou por no ar que >> alem de php com acesso >> a mysql, tem muito acesso a arquivos staticos de pequeno tamnho, 15K em >> media.. > > Nesse caso faça como YouTube: estatico no lighttpd e dinamico no Apache. > Lighttpd tem até 18% mais performance pra servir arquivos estáticos. > >> Entao achei que em funcao da maioris dos hits (80%) ser de arquivos >> estaticos, o dso poderia gerar >> um overhead desnece
Re: [FUG-BR] bloquear https com squid
Axo que o erro pode estar no firewall, vc esta direcionando a porta 443 ? Pois tanto no autenticado como no transparente o bloqueio funciona 2008/12/16 Renato Botelho > On Tue, Dec 16, 2008 at 12:49 PM, Ricardo Augusto de Souza > wrote: > > Ola, > > eu utilizo a forma abaixo para bloquear alguns domínios: > > > > acl bad_sites dstdomain "/etc/squid/bad_sites.txt" > > > > http_access deny bad_sites > > > > > > Porém os usuarios conseguem acessar os sites via https. > > > > Como vcs bloqueiam sites ( http e https ) ? > > O que deve estar acontecendo é que você usa proxy transparente, > correto? > > Se for isso, não existe maneira pra bloquear https, agora se você > usa autenticado, então com essas regras ele deveria bloquear os > dois. > > -- > Renato Botelho > - > 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] bloquear https com squid
On Tue, Dec 16, 2008 at 12:49 PM, Ricardo Augusto de Souza wrote: > Ola, > eu utilizo a forma abaixo para bloquear alguns domínios: > > acl bad_sites dstdomain "/etc/squid/bad_sites.txt" > > http_access deny bad_sites > > > Porém os usuarios conseguem acessar os sites via https. > > Como vcs bloqueiam sites ( http e https ) ? O que deve estar acontecendo é que você usa proxy transparente, correto? Se for isso, não existe maneira pra bloquear https, agora se você usa autenticado, então com essas regras ele deveria bloquear os dois. -- Renato Botelho - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Apache22+php5 - mod_php ou fastcgi ?
Leonardo Augusto escreveu: > Ola Patrick.. > > Pois é... tudo que voce disse faz sentido.. > A minha duvida entre os dois modos de operacao se deu no seguinte sentido.. Ola Leonardo, > > apache+php via fastcgi: > --- > pelo que entendi, e quando rodei nessa configuracao eu vi, que ficam > varios php-cgi startados.. Perfeito, na verdade um php-cgi para cada instância simultânea que chegou a acontecer. > aí quando chega um request que lida com php, o apache comunica direto > com um desses Exato, um monte de syscall passando o arquivo de uma aplicacão pra outra via socket local. > processos cgi que ja estao rodando, via o fastcgi.. > Li que isso teria vantagens quando alem de php o site trata muito > arquivo estatico, o que seria Na verdade não da pra ter vantagem tecnicamente. Ao inves de termos uma aplicacao que ja sabe como processar, associando a extensao a um handler interno que sabe o que fazer, temos na verdade uma aplicacao que associa a extensao a um handler que nao sabe o que fazer so sabe que tem que passar pra um socket local, e esperar a resposta pronta. Nesse caso o trabalho do Apache eh mais leve simplesmente porque ele delega o trabalho pesado ao CGI. Isso gera várias syscalls adicionais, e consequentemente overhead adicional. Sobre estático VS dinamico da na mesma visto que a associacão de tipos é por extensão em ambos os casos. Quando se fala de servir estático a comparação deve ser Apache VS LightHTTP não Apache+PHP-FCGI VS Apache+PHP-DSO > vantagem pois o apache nao teria que carrega o modphp a cada fork.. Então, funciona assim. Se tem que haver o fork de um novo child process sim, todos os modulos DSO sao carregados a cada fork. Sem execao. Isso inclui o modulo fastcgi do PHP rodando em modo fcgi. Nao faz diferenca. A questão é que se for fast-cgi temos ainda outra questão, além dos fork do apache tem ainda o fork de novos php-cgi. O Apache funciona assim, quando vc inicia ele inicia StartServers instancias, nesse caso cada um dlees ja tem o PHP em DSO carregado. Depois de StartServer+1 ele vai carregar MinSpareServers de uma vez, e eles teão o PHP em DSO. Porém se você tem o PHP em FCGI os StartServers vão chamar o modulo que joga as requisicoes pro fastcgi, que joga sua vez pro spawn-fcgi que por sua vez iniciam o php-cgi. Isso acontece para cada vez que uma nova instancia httpd for iniciar que consuma php via fastcgi. > tudo bem.. mas até ai poderiamos deixar como vc disse rodando pelo > menos 512 processos do > apache com dso e esse delay no fork nao seria problema correto ? Correto, é possível, mas não fica acontecendo fork todo o tempo, so quando ha mais requisicoes simultaneas do que novos processos iniciados. > > apache+php via dso > > pois é, nesse caso o gargalo seria se ouvessem muitos forks atrelados > ao grande numero de hits.. > até ai tambem se deixar uma grande quantidade de processos sempre > startados do apache acho > que nao deve ser problema.. > > Essa minha duvida surgiu em funcao de um servico que vou por no ar que > alem de php com acesso > a mysql, tem muito acesso a arquivos staticos de pequeno tamnho, 15K em > media.. Nesse caso faça como YouTube: estatico no lighttpd e dinamico no Apache. Lighttpd tem até 18% mais performance pra servir arquivos estáticos. > Entao achei que em funcao da maioris dos hits (80%) ser de arquivos > estaticos, o dso poderia gerar > um overhead desnecessario.. O cgi vai gerar bem mais overhead não só no startup dos processos child mas em toda operacão php. > No final, acho que vou deixar o apache+php em dso para tratar a > interacao com mysql, e vou por um jail > noutro ip com o lighttpd apenas para suprir as paginas estaticas... > > O que vc acha ? Faz bem :D Nem precisa de Jail, o mod_rewrite resolve se voce rodar um webserver na 80 e outro noutra porta. > Assim eu eliminaria o risco de o grande numero de requisicoes > estaticas "laguear" o php<->mysql no apache.. > > Ou sera que nao há necessidade disso ? Não sei qual sua expectativa de demanda em numeros de hits/s? E qual tipo de processamento PHP? É fácil rodar um ab fazendo bench pra testar isso. > > Estou usando freebsd 7.1(o ultimo la) num dual quad core 2.66 com 8G > de ram e um raid 10 com scsi 15k rpm. > > Só quero fazer o melhor ajuste nessas apps para para nao porem a culpa > no freebsd, > ja que todo mundo quer usar linux e eu que opto pelo freebsd, eheh > > Bom, valeu pelos comentarios Patrick. > > []'s > > > > > > > > > 2008/12/15 Patrick Tracanelli : >> Leonardo Augusto escreveu: >>> Ola, >>> >>> Tenho pesquisado na net e vi alguns comentarios que o php5 tem um >>> desempenho melhor no apache22 se for usado via mod_fastcgi.. >>> ao inves de mod_php >>> >>> O argumento é que o core do php nao é carregado pelo apacha a cada >>> instancia do servidor... >>> E para o mod_php ainda nao funciona bem com o tal do m
[FUG-BR] bloquear https com squid
Ola, eu utilizo a forma abaixo para bloquear alguns domínios: acl bad_sites dstdomain "/etc/squid/bad_sites.txt" http_access deny bad_sites Porém os usuarios conseguem acessar os sites via https. Como vcs bloqueiam sites ( http e https ) ? valeu - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Apache22+php5 - mod_php ou fastcgi ?
Ola Patrick.. Pois é... tudo que voce disse faz sentido.. A minha duvida entre os dois modos de operacao se deu no seguinte sentido.. apache+php via fastcgi: --- pelo que entendi, e quando rodei nessa configuracao eu vi, que ficam varios php-cgi startados.. aí quando chega um request que lida com php, o apache comunica direto com um desses processos cgi que ja estao rodando, via o fastcgi.. Li que isso teria vantagens quando alem de php o site trata muito arquivo estatico, o que seria vantagem pois o apache nao teria que carrega o modphp a cada fork.. tudo bem.. mas até ai poderiamos deixar como vc disse rodando pelo menos 512 processos do apache com dso e esse delay no fork nao seria problema correto ? apache+php via dso pois é, nesse caso o gargalo seria se ouvessem muitos forks atrelados ao grande numero de hits.. até ai tambem se deixar uma grande quantidade de processos sempre startados do apache acho que nao deve ser problema.. Essa minha duvida surgiu em funcao de um servico que vou por no ar que alem de php com acesso a mysql, tem muito acesso a arquivos staticos de pequeno tamnho, 15K em media.. Entao achei que em funcao da maioris dos hits (80%) ser de arquivos estaticos, o dso poderia gerar um overhead desnecessario.. No final, acho que vou deixar o apache+php em dso para tratar a interacao com mysql, e vou por um jail noutro ip com o lighttpd apenas para suprir as paginas estaticas... O que vc acha ? Assim eu eliminaria o risco de o grande numero de requisicoes estaticas "laguear" o php<->mysql no apache.. Ou sera que nao há necessidade disso ? Estou usando freebsd 7.1(o ultimo la) num dual quad core 2.66 com 8G de ram e um raid 10 com scsi 15k rpm. Só quero fazer o melhor ajuste nessas apps para para nao porem a culpa no freebsd, ja que todo mundo quer usar linux e eu que opto pelo freebsd, eheh Bom, valeu pelos comentarios Patrick. []'s 2008/12/15 Patrick Tracanelli : > Leonardo Augusto escreveu: >> Ola, >> >> Tenho pesquisado na net e vi alguns comentarios que o php5 tem um >> desempenho melhor no apache22 se for usado via mod_fastcgi.. >> ao inves de mod_php >> >> O argumento é que o core do php nao é carregado pelo apacha a cada >> instancia do servidor... >> E para o mod_php ainda nao funciona bem com o tal do mpm.. que >> resolveria esse problema.. >> >> É melhor entao usar o php via mod_fastcgi ? > > Pessoalmente não sei não, não vejo sentido nisso. A grande vantagem de > performance do php no Apache é exatamente o modulo DSO. O que você deve > ter lido foram duas coisas, a performance no Apache 2.2 é menor (quando > comparado com Apache 2.0) e o carreamento da nova instância é mais > lento. Já li ambos e o primeiro fato eu não avaliei, o segundo fato não > faz sentido: > > - Ao invés de um novo httpd com o DSO do php, o cgi carrega um novo > php-cgi via spawn-fcgi; como pode ser mais rápido? Conte comigo as > chamadas de sistema, ao invles de 1 malloc pro DSO são um execve+fork > pro httpd carregar o spawn-cgi, que por sua vez faz 1 malloc+execve+fork > para carregar o php-cgi; em cada instância "nova"; > > - Depois disso cada instrucão processada pelo PHP é enviada através de > socket local para o php-cgi, quee processa e devolve tambem via socket > para o Apache; são cerca de 4 syscalls a mais por operacão, que não > existe no caso do uso de módulo DSO; > > - Finalmente, se há qualquer diferenca de performance é no startup da > instância do servidor. Isso é problema? Aumente o MinSpareServers e vai > startar todos ao custo de 1 syscall de malloc por DSO e 1 syscall > fork/execve ao invés de várias por instância; > > - Só pode ser problema para quem usa MaxRequestsPerChild diferente de 0 > no Apache. Ainda assim se for um valor muito baixo (tipo 2) para o > MaxRequestsPerChild; > > Por último, se o custo de carregar o DSO do php é tão grande, porque não > é com o mod_access, o mod_ssl, com WebDAV, e mais N módulos DSO > extremamente populares que o sistema carrega em cada instância? > > Logico, to falando com base no Apache 2.0; No 2.2. porem ainda que haja > mesmo essa diferenca de performance se for tão crítica ao ponto de fazer > uma implementacão mais pesada ficar mais rápida é um problema no mínimo > crucial, pq o framework de DSO do Aapche é o basico dele. > > Sei que o PHP em modo CGI tem como vantagem pode ser executado com > privilégio do usuário dono do script, ao invés de ser com usuário do > Webserver. Em ambiente compartilhado isso pode aumentar a performance; > por outro lado em DSO temos os php_admin_flags|value da vida > configuráveis por contexto; o que temos de equivalente via CGI? Trocar > variáveis de ambiente não serve, o programador redefine elas quando bem > entender. > > O fato acima só pra considerar que nem tudo é performance. Segurança na > minha opinião é mais critico e ai sim pode haver uma conversa > interessante sobre fastcgi VS DSO. > > -- > Patr
Re: [FUG-BR] Sistema de Workflow para FreeBSD
> Olá caros amigos, > > Sabe onde eu poderia encontrar um sistema de workflow free básico para > funcionamento no FreeBSD? > > > Aguardo respostas Procure workflow open source. São independentes do sistema operacional. Eu gosto do galaxia apesar da interface "tosca" dele. O e-Groupware também tem um bem interessante e altamente customizável. De qualquer forma se voce procurar no search do www.sf.net vai ter um monte de opcões pra avaliar. Todas rodam em FreeBSD. > > Valeu > ca_prog. > > > Veja quais são os assuntos do momento no Yahoo! + Buscados: Top 10 - > Celebridades - Música - Esportes > > > Veja quais são os assuntos do momento no Yahoo! +Buscados > http://br.maisbuscados.yahoo.com > - > 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
