Re: [FUG-BR] RES: OFF-IP da interface serial do Router
Então veja só ping -i 1 www.uol.com.br Reply from 172.24.10.254: TTL expired in transit. (Gateway) ping -i 2 www.uol.com.br Reply from 189.YY.YY.1: TTL expired in transit. (IP LAN do Router) ping -i 3 www.uol.com.br Reply from 189.17.239.117: TTL expired in transit. (IP Serial da Router) Então a interface serial da Operadora seria 189.x.x.118 mascara 255.255.255.252. Seria isso ? O IP da serial da Operadora é sempre Par ?? Quem respondeu no caso do ttl 3 foi o router da operadora, ou seja o IP 189.17.239.117/30 é o da operadora. O seu IP (no seu roteador) é o 189.17.239.118/30. Veja que quem responde é sempre o gateway (primeiro o seu gateway internet, depois o seu router e em seguida o router da operadora). Traceroute ou tcptraceroute tem o mesmo efeito... Luiz - 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: OFF-IP da interface serial do Router
ping -i 1 www.uol.com.br vai ter resposta assim: Pinging www.uol.com.br [200.98.249.120] with 32 bytes of data: Reply from 10.1.0.1: TTL expired in transit. Bom, ela não disse que os pacotes estão expirando, disse que não aparecem os IPs das bordas do link. Bem, existem a possibilidade de se utilizar links ppp sem IP. Como o ppp é um link PONTO-A-PONTO todo dado que você roteia na sua porta vai aparecer religiosamente na porta da operadora (salvo problemas de fé). Para esses casos a cisco tem o ip unnumbered onde o router utiliza apenas o ip da ethernet (não precisa ip na serial). Não vejo isso em uso a algum tempo... (o primeiro link de internet que ativei na ebt utilizava essa configuração... 64Kb em 96... R$7.000 por mês :/) Nesse caso você só vê o IP da ethernet do roteador na outra ponta (não muda muito, certo ?). Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Ajuda em pkg_add
/rant felizmente NÃO, NÃO MESMO!.. Nem isso, nem iptables, aquela coisa horrorosa e de sintaxe esdrúxula. /end rant hahahaha indeed! A opção apt-get não tem no Freebsd, né? Leia o HandBook (É PRA LER MESMO) e esqueça que você usa linux quando estiver no FreeBSD. Linux users: infelizmente (depois de algumas aulas de linux que tivemos aqui na lista apt.conf != HTTP Proxy no linux) dizer aqui que você tem conhecimentos avançados em linux simplesmente não ajuda... é só outro usuário cheio de manias, cheio de conlusões erradas e achando que o mundo gira em torno do linux. Por favor, mostrem um pouco de respeito com aquilo que vocês não conhecem e procurem ler, procurem se informar antes de dar mais aulas aqui na lista. Na pior das hipoteses você terá aprendido algo novo (se você não precisa aprender o que esta fazendo aqui na lista ?). Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] LM77 thermal monitor
Alguem sabe se no FreeBSD existe suporte ao sensor LM77 da National ? Algum software, configuração especifica.. Edgar, O que você precisa fazer ? O LM77 é um sensor de temperatura i2c... isso esta no seu micro ou você quer só ligar ele ? Você vai precisar do datasheet do lm77 e uma boa lida nos manuais iicbus(4), lpbb(4) e o i2c(8). Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Pen Drive de 32 GB
Pessoal, Os que eu comprei aqui em Tokyo, eram Kingston, mas tanto no FreeBSD, Fedora, Debian e Win Vista, onde usei ele, não tive problema algum. Não sei do preço aí, mas aqui, estavam em torno de US$ 100 (￥9980). Abraços, Watanabe. Fomos encarregados de comprar alguns sticks 64GB a algumas semanas... Naquela semana achamos apenas em dois lugares na sta. ifigênia, um deles deu esse problema que o João comentou (estava escrito 64GB mas a capacidade detectada era outra), na segunda loja, tudo (aparentemente) certo, preço: R$ 50,00 (estão te roubando ai em tokyo :) ). A noite me pediram pra testar o memory stick, me arrumaram um notebook com vista e depois de alguns problemas (windows é tão esperto que não permite a cópia dele mesmo) consegui colocar +- 8GB no stick. Uma semana depois me chamaram de volta para apagar o memory stick, ninguem conseguiu apagar os dados em nenhuma maquina :) Espetei o bixo no FreeBSD mandei um newfs_msdos, estranho, apagou na hora (será que tinha vírus ?) :) No FreeBSD reconheceu os 64GB certinho. []'s Luiz PS: Um dos sticks já havia sido testado na loja e estava repleto de vírus... Isso é uma praga... - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Pen Drive de 32 GB
Não sei dizer se estão me roubando aqui, mas tenho certeza, que em qualquer loja decente em Akihabara, os preços são esses mesmos. A propósito, aqui, os Watanabe, Foi só uma brincadeira, não queira comparar as lojas decentes dai com os shoppings da sta. ifigênia... Na sta. ifigênia te roubam de verdade... já meteram o cano na cara de um conhecido meu... aparece lá de terno, iphone e notebook... depois me conta... []'s Luiz - 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) Fundação Apache tem servidor es crackeados.
Welkson Renny de Medeiros escreveu: Alessandro de Souza Rocha escreveu: link: http://www.noticiaslinux.com.br/nl1251679441.html link: https://blogs.apache.org/infra/entry/apache_org_downtime_initial_report Nesta sexta-feira os servidores da fundação Apache apresentaram durante algumas horas uma página informando que estavam investigando um incidente em seus servidores. Ao que parece, primeiro foi comprometido via SSH o servidor minotaur.apache.org, depois partiu-se para o resto da infraestructura incluindo www.apache.org onde foram instalados diversos arquivos. Segundo a Apache a investigação continua e por enquanto não tem conhecimento dos usuários finais afetados, ainda que recomendem efetuar a verificação da assinatura dos arquivos. Não é a primeira vez que o apache.org é comprometido, sendo a anterior em 2005. Não tem a DATA, mas pode ter sido isso: http://www.dataloss.net/papers/how.defaced.apache.org.txt Algumas dúvidas que fiquei... pelo que li o FreeBSD usado é o 3.4... no release note vejo que o mesmo foi lançado em OUTUBRO de 1999 (quase 10 anos). Essa versão ainda tem suporte? Eles comentam sobre MYSQL com senha root em branco, diretório wwwroot com direito de execução, etc... mas como eles conseguiram entrar? falha DNS? Segundo as informações no blog do apache não se trata do mesmo problema (esse descrito no dataloss). O blog do apache diz que foram copiados arquivos para a maquina utilizando uma chave de ssh (resta saber como essa chave foi comprometida), mas não da maiores detalhes. Nas informações do dataloss, um arquivo php foi upado via ftp e o root do ftp era o mesmo do www, havia falha nas permissões e foi possível colocar o arquivo de forma que o mesmo pudesse ser executado via web. Em seguida foi utilizado o mysql que estava rodando como root para gerar arquivos que instalavam um copia do shell com suid bit (pode ser executado por qualquer usuário e rodará como root). A parte interessante é que o mysql só gerou um script que precisava ser executado pelo root de verdade, por isso o arquivo foi gerado como /root/.tcshrc que foi executado no proximo login real do root (ou su -). Foi só esperar até o proximo login do root e correr pro abraço ;) Até pela versão do FreeBSD, esse relato deve ser bem antigo... No blog do apache eles dizem que a maquina afetada rodava FreeBSD-7-STABLE. []'s Luiz - 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) Fundação Apache tem servidor es crackeados.
Dizem que a falha foi no SSH. Não foi falha do SSH já que o acesso foi feito por meio de chaves de autenticação (a chave de alguem vazou ou foi comprometida previamente)... Se foi falha do ssh a coisa é feia... pior se quebraram a chave de autenticação... Luiz - 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: RES: Testando ipfw nat
Você tem referencias desses exemplos ? Eu andei estudando - fazendo meu dever de casa - (e até mesmo incomodando alguns dos desenvolvedores) com relação a esse assunto, mas o roteamento no freebsd é, digamos, _complexo_ e eu estou longe de conhecer todos os detalhes da implementação (embora já tenha uma certa idéia de como as coisas funcionam por ali). Toda informação disponivel é sempre bem-vinda. []'s Luiz Boa noite. Luiz, infelizmente não tenho os links para referencias, mas foram vários exemplo que pude ver em diversos fóruns por ai. Se você tive alguma coisa falando sobre as tabelas FIB me envie por gentileza. Bom final de semana! Wanderson, A unica documentação oficial (quem nem chega a ser uma documentação...) é o log do commit feito pelo Julian Elisher: http://svn.freebsd.org/viewvc/base?view=revisionsortby=daterevision=17 Ainda assim esse material é bem tecnico e não da muitos exemplos de utilização, mas foi essa a documentação mais completa e que mais me ajudou a entender as FIBs até o momento. Bom fim de semana ! Luiz - 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: RES: Testando ipfw nat
Wanderson, Ricardo e lista,
Para o correto funcionamento do setfib é necessário tomar alguns cuidados
(e
observar algumas limitações que vou comentar).
Cada FIB representa uma tabela de roteamento distinta e as FIBs só estão
disponíveís para o protocolo IPv4 (não há multiplas fibs para outros
protocolos...).
Como a fib representa uma tabela de roteamento os pacotes devem ser
marcados
ANTES do roteamento com a fib que você deseja utilizar e as únicas forma
de
fazer isso é:
- Na recepção dos pacotes pela sua placa conectada à rede interna: ipfw
setfib 1 ip from 192.168.0.0/24 to any IN via ${iif}
- Rodando um programa no FreeBSD com o utilitário setfib: setfib 1 ping
www.uol.com.br
Assim os pacotes são marcados com a fib desejada ANTES do roteamento, que
vai olhar para a tabela fib que você selecionou.
Setar a fib na saída dos pacotes ou depois que o roteamento já foi feito
simplesmente não funciona.
Outro detalhe é que o ipfw prob não respeita os fluxos, ou seja, uma
conexão
que é iniciada utilizando aquela regra pode ter seus próximos pacotes
seguindo outro caminho (não sei dizer ao certo se a interação com o
keep-state resolve isso - poderia resolver).
E para terminar eu diria que as tabelas FIBs não devem ser utilizadas
para
balanceamento das conexões, mas sim para pbr, ou seja, aquele tipo de
pré-seleção que você faz para dizer que a maquina X ou o recurso Y
utilizam
o link 2 enquanto a navegação é feita pelo link 1.
E vocês viram que eu nem falei de nat...
Eu já consegui um hardware aqui pra fazer os testes no freebsd 8, mas vai
levar algum tempo... (tem uma pilha de coisas esperando aqui...), dai
pretendo postar mais detalhes do balanceamento com ipfw.
Att.,
Luiz
Luiz Otávio, obrigado por esse esclarecimento, acabei por marcar o pacote
entrando pela interface interna e funcionou. Tenho visto muitos exemplos
pela net bem diferente da sua explicação.
Você tem referencias desses exemplos ?
Eu andei estudando - fazendo meu dever de casa - (e até mesmo incomodando
alguns dos desenvolvedores) com relação a esse assunto, mas o roteamento no
freebsd é, digamos, _complexo_ e eu estou longe de conhecer todos os
detalhes da implementação (embora já tenha uma certa idéia de como as coisas
funcionam por ali).
Toda informação disponivel é sempre bem-vinda.
Em um post 'meio-recente' você comentou ter tido problemas no freebsd 8
quando forçava a saída do pacote com fwd pela segunda fib, foi preciso
desabilitar a sysctl flowtable eu acho, isso confere?
Sim, confere... houve uma primeira tentativa de correção (r196234 -
2009-08-14) mas que acabou criando outro problema e esse só foi corrigido
agora (r196608 | qingli | 2009-08-28 02:37:31).
E isso quer dizer que as correções estarão disponíveis no 8.0-RELEASE
(espero) e que a solução final foi commitada depois do BETA-3.
Não tenho certeza se essas correções já foram mfced - copiadas para o
stable/8... mas estão no head e nesse caso é só uma questão de tempo.
Na duvida sysctl net.inet.flowtable.enable=0 resolve :)
[]'s
Luiz
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Nat e Roteamento em 2 Gateways
http://img402.imageshack.us/img402/7439/wireless.png resolvi deixar de lado o lance de natear os clientes (através de wireless) que estarão conectados a partir deste gateway segundário pelo menos assim com as rotas eu consigo alcançar todos os clientes e antenas etc... deixei o nat para o servidor principal porém, a partir do note, que está atras do outro gate, eu navego normalmente como se o se IP (rede 10) estivesse nateado, e mesmo não estando nateado, pois deixei nat somente para o ip da lan que está no segundo gate (192.168.0.3) se eu removo a regra nat para o segundo gate (ip 192.168.0.3) ai o notebook ip 10.10.10.2 deixa de navegar o estranho é que eu notei perfeitamente que, se eu der ping a partir do note com destino ao gateway principal, eu vejo os pacotes icmp pelo iptraf do gate principal, isso confirma que com as rotas, as redes estão alcançáveis, correto O que você consegue ver no seu gateway principal (linux) quando você pinga do notebook para a internet (tcpdump) ? Você ve o IP 10.x.x.x ou o IP 192.168.0.3 ? Possívelmente o freebsd ainda esta fazendo nat e convertendo os ips 10.x.x.x para o 192.168.0.3 ou o linux esta fazendo o nat do IP 10.x.x.x. Luiz - 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: FreeBSD 64 bits e alguns softwares
64bits é a escolha natural nos dias de hoje, cedo ou tarde será necessário adicionar mais de 4GB de RAM no servidor e daí 32bits não atende. Tirando uma única flag diferente para compilar o vpopmail(que já postei aqui), não observei nada diferente para rodar o free em 64bits. É isso mesmo Renato... 4G nos dias de hoje não parece muito e possívelmente teremos mais memória nos servidores novos... O port amd64 já é bem maduro e dificilmente você encontrará problemas com qualquer software. Quanto ao zfs, até o momento só alegria (e olha que o servidor já me deu muito trabalho - muito boot no dedo, muito crash) e só estou rodando com 2GB de memoria: last pid: 59242; load averages: 0.00, 0.00, 0.00 up 19+21:25:36 07:40:39 39 processes: 1 running, 38 sleeping CPU: 0.4% user, 0.0% nice, 0.4% system, 1.7% interrupt, 97.5% idle Mem: 63M Active, 14M Inact, 757M Wired, 392K Cache, 33M Buf, 1133M Free Swap: 8192M Total, 8192M Free # uname -a FreeBSD fw-sp.xxx.com.br 8.0-BETA2 FreeBSD 8.0-BETA2 #8 r195941M: Thu Jul 30 21:17:10 BRT 2009 r...@fw-sp.xxx.com.br:/usr/src/sys/amd64/compile/FW amd64 O servidor esta em produção desde antes do BETA2, só depois é que foi atualizado. Só uma dica para quem vai instalar o amd64, aumente o tamanho da partição / (por conta do /boot), cada kernel compilado ocupa +- 250MB, aquela partição recomendada (ou automatica) do instalador (512MB) é pequena: # du -d1 /boot/ 22 /boot/defaults 2 /boot/firmware 237476 /boot/kernel 2 /boot/modules 4 /boot/zfs 237230 /boot/kernel.orig 237476 /boot/kernel.old 713156 /boot/ []'s Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] FreeBSD 64 bits e alguns softwares
Verdade Luiz, sempre uso 1GB para o / Outro detalhe, o ZFS é consumidor de memória? Se for, mais um motivo para largar i386 e adotar de vez amd64. Sim o zfs consome alguma memoria para buffer, mas como você viu, esta funcionando com folga nesse servidor com 2GB de memória e mirror de dois discos: last pid: 59329; load averages: 0.00, 0.00, 0.00 up 19+21:58:06 08:13:09 37 processes: 1 running, 36 sleeping CPU: 0.0% user, 0.0% nice, 1.9% system, 1.9% interrupt, 96.2% idle Mem: 62M Active, 14M Inact, 756M Wired, 392K Cache, 33M Buf, 1136M Free Swap: 8192M Total, 8192M Free %zpool status pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 mirror ONLINE 0 0 0 ad8s3d ONLINE 0 0 0 ad10s1d ONLINE 0 0 0 errors: No known data errors %zpool list NAME SIZE USED AVAILCAP HEALTH ALTROOT tank 224G 4.55G 219G 2% ONLINE - %zfs list NAMEUSED AVAIL REFER MOUNTPOINT tank 4.55G 216G18K none tank/root 27.2M 216G 27.2M legacy tank/tmp636M 216G 636M /tmp tank/usr 3.81G 216G 3.81G /usr tank/var 93.8M 216G 93.8M /var - 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: RES: 4 ethers no mesmo range de IP
172.31.1.53 255.255.255.255127.0.0.1127.0.0.1 20 172.31.1.55 255.255.255.255127.0.0.1127.0.0.1 20 veja que o windows deu o jeito dele :P É isso mesmo Alexandre, o windows não prende as rotas a uma interface física... isso resolve alguns problemas (usuários configurando duas placas distintas no mesmo range) e cria outros (por exemplo não se pode fazer o roteamente de interfaces ptp sem IP - ip unnumbered nos cisco like). Luiz - 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: RES: 4 ethers no mesmo range de IP
neste caso o freebsd não daria o jeito dele ?? 2009/8/26 Alexandre Correa alexan...@sabbath.com.br: 172.31.1.53 255.255.255.255 127.0.0.1 127.0.0.1 20 172.31.1.55 255.255.255.255 127.0.0.1 127.0.0.1 20 veja que o windows deu o jeito dele :P Sim, o jeito do FreeBSD é o faça certo e faça uma vez só ou ainda não esconda os erros dos usuários :) As tabelas de roteamento e arp foram reescritas no freebsd-8 e na melhor das hipóteses, só aumentou a necessidade de fazer a coisa certa, nada foi facilitado e veja que isso vem de encontro com as RFCs. Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] kernel: arp: unknown hardware address format (0x4500)
Pessoal depois de atualizar para a versão Stable o FreeBSD 7.2 apresenta esses erros no log kernel: arp: unknown hardware address format (0x4500) alguém sabe o que quer dizer? Não tenho certeza se isso tem a ver com o upgrade que você fez... Quem dispara esses erros são pacotes corrompidos de arp-request e/ou arp-reply na sua rede. Talvez o tcpdump (-e) ajude você a identificar quem (ou o que) esta mandando esses pacotes para a sua rede. O unico problema que pode acontecer na atualização é a falta de sincronismo entre o kernel e userland (atualização incompleta). Att., Luiz - 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: RES: Testando ipfw nat
lan 192.168.17.0/24, adsl 192.168.29.yyy. Acontece que num caso temos REDE 17 e no adsl REDE 29. Não combina. Pelo que aprendi (ou me ensinaram, sei lá, ou tentaram), são redes distintas portanto NÃO DEVERIAM se falar.. conferindo com o ipcalc tive demonstração de que estou certo, mas sei lá.. será que algo mudou de uns tempos pra cá? Irado, Ele vai rotear (ou fazer) da rede 192.168.17 para a rede 192.168.0.29, por isso são redes distintas. Elas vão se falar através do freebsd (roteador). []'s - 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: RES: Testando ipfw nat
ipfw -f flush
ipfw add 1 check-state
ipfw add 10 prob 0.5 setfib 0 tag 1 all from any to any keep-state
ipfw add 11 setfib 1 tag 2 all from any to any keep-state
ipfw add 20 nat 1 all from any to any tagged 1
ipfw add 21 nat 2 all from any to any tagged 2
ipfw add 30 allow all from any to any
Wanderson, Ricardo e lista,
Para o correto funcionamento do setfib é necessário tomar alguns cuidados (e
observar algumas limitações que vou comentar).
Cada FIB representa uma tabela de roteamento distinta e as FIBs só estão
disponíveís para o protocolo IPv4 (não há multiplas fibs para outros
protocolos...).
Como a fib representa uma tabela de roteamento os pacotes devem ser marcados
ANTES do roteamento com a fib que você deseja utilizar e as únicas forma de
fazer isso é:
- Na recepção dos pacotes pela sua placa conectada à rede interna: ipfw
setfib 1 ip from 192.168.0.0/24 to any IN via ${iif}
- Rodando um programa no FreeBSD com o utilitário setfib: setfib 1 ping
www.uol.com.br
Assim os pacotes são marcados com a fib desejada ANTES do roteamento, que
vai olhar para a tabela fib que você selecionou.
Setar a fib na saída dos pacotes ou depois que o roteamento já foi feito
simplesmente não funciona.
Outro detalhe é que o ipfw prob não respeita os fluxos, ou seja, uma conexão
que é iniciada utilizando aquela regra pode ter seus próximos pacotes
seguindo outro caminho (não sei dizer ao certo se a interação com o
keep-state resolve isso - poderia resolver).
E para terminar eu diria que as tabelas FIBs não devem ser utilizadas para
balanceamento das conexões, mas sim para pbr, ou seja, aquele tipo de
pré-seleção que você faz para dizer que a maquina X ou o recurso Y utilizam
o link 2 enquanto a navegação é feita pelo link 1.
E vocês viram que eu nem falei de nat...
Eu já consegui um hardware aqui pra fazer os testes no freebsd 8, mas vai
levar algum tempo... (tem uma pilha de coisas esperando aqui...), dai
pretendo postar mais detalhes do balanceamento com ipfw.
Att.,
Luiz
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Convite para a comunidade participar de f órum
Are you a robot? Att; Enrique Fynn. O fórum ficará ativo até o dia 15/08/09. Enrique, Você ainda tem dúvida ? =) Para o bem da lista espero que isso acabe no dia 15 ou que algum moderador o faça antes. []'s - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] divert(4)
Otacílio, boa tarde. Desculpe se eu não entendi bem, mas você consegui pelo menos obter uma copia dos pacotes pelo seu programa que escuta na porta 2508 usando a opção tee? ipfw add tee 2508 ip from any to any Os pacotes que estão saindo para a internet estão passando pela porta 2508 sem problemas. O programa pega os pacotes, faz o que tem que fazer e envia novamente. Os pacotes chegam para o novo endereço na mesma máquina. O problema é na hora da volta. Ao que parece, eles não estão passando pelo divert porque os dois endereços são da mesma máquina. Quando o pacote deve ir para internet funciona, mas quando os pacotes tem endereços da mesma máquina como destino parece que as camadas de rede apenas entregam os pacotes sem descer para as camadas mais baixas e passar pelo divert. Por acaso você não esta com o net.inet.ip.fastforwarding habilitado, não é ? Mande o resultado do que acontece com os pacotes segundo o ipfw: ipfw add 1 count log ip ... []'s Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Remover o Openssl
Lista, Quando instalamos o freebsd, ele instala openssl, gostaria de remove-lo, como procedo? -- Att, Válter Júnior Valter, Qual a sua intenção final ? Por que você quer/precisa remover o openssl ? O openssl é instalado na base do sistema. Você pode adicionar a opção WITHOUT_OPENSSL=YES no /etc/src.conf e recompilar o seu sistema para gerar uma versão sem dependencia do openssl (maiores informações no handbook e src.conf(5)). Agora se você precisa apenas de uma versão diferente, instale o openssl do ports. Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Fwd: FreeBSD 8.0-BETA1 Available
e facil, faz um script e coloca /etc/rc.d e o conteudo setfib 0 route add default 10.1.1.1 setfib 1 route add default 10.0.0.1 Ou adicione os comandos no /etc/rc.local (que é padrão para todo sistema unix...). Realmente não existem variaveis e scripts para tratar as FIBs nos scripts de inicialização (que leem o rc.conf). []'s Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Remover o Openssl
Caro Renato, Como disse, estou a semanas fazendo testes e reinstalações, por isso eu afirmo, que esta opção não funciona, possa ser que eu esteja, errando em alguma coisa que mesmo com todo este tempo, não tenha observado, já que um detalhe pode derrubar o melhor dos técnicos, mas por enquanto, comigo não funcionou. Valter, O que o Renato esta tentando dizer é que o openssl instalado no FreeBSD _não_ tem qualquer problema e isso porque muitas aplicações são compiladas utilizando as bibliotecas do openssl e todas essas aplicações funcionam muito bem. Qualquer problema no openssl do sistema seria rapidamente percebido por uma grande quantidade de usuários. Outro ponto é que (todos) nós utilizamos várias soluções de e-mail que utilizam ssl (qmail, courier-imap, aplicações ssl desenvolvidas em casa entre outros) e todos funcionam. Então ou você tem um problema no port do qpopper (que eu não conheço e não posso entrar em detalhes - tente instalar o qpopper na mão para testar) ou há algum problema no seu setup, porém o problema dificilmente esta relacionado ao openssl do freebsd. Claro que não estamos ai para ver o que realmente esta acontecendo e podemos estar muito enganados, mas historicamente é assim que percebemos o problema. Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] XFS e JFS
Luiz.. fiquei com uma dúvida referente a tua resposta O apache como servidor http fica a mais ou menos um dois anos luz atras do lighttpd... (acredite a diferença _é_ gritante). Aqui quando você fala em utilizar o lighttpd no lugar do Apache, como seria a configuração equivalente a Apache2.2 + mod_cache + mod_deflate + mod_expires. Não encontrei para o lighttpd, um módulo de cache nos moldes do mod_cache do apache. Na verdade, gostaria de saber qual a configuração vc me aconselharia a usar, para um GRANDE volume de dados. ;-) Fabio, A idéia não era fazer você utilizar o lighttpd e sim fazer uma comparação para dizer que o apache não é o primeiro software que vem a cabeça quando se pensa em desempenho. Como comentei nenhum dos dois foi ou é otimizado para cache pesado e sim para soluções pequenas e rápidas... Para o volume que você citou eu ficaria com o squid/lusca, ambos trabalham tranquilamente com essa quantidade de dados. Mas é dificil dar opniões sem conhecer melhor o seu ambiente e necessidade. Agora a informação que tudo isso roda sob nfs foi muito importante, pois por si só o nfs é praticamente um sistema de arquivos e (dependendo do caso) pode arruinar o desempenho do fs que ele esta exportando, seja ele qual for. Agora falando de fs, segue o trecho de uma mensagem que circulou na current@ para que você ter uma idéia de como os gringos estão utilizando o zfs e o seu desempenho (by Freddie Cash - detalhe nos 46 drives ! isso mesmo quarenta e seis HDs !): We remade the pool using 3x 8-drive raidz2 vdevs, and performance has been great (400 MBytes/s write, almost 3 GBytes/s sequential read, 800 MBytes/s random read). Yep that corresponds with what we saw, although we were getting a little higher write rates with our 46 drive configuration []'s Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] tabela fibs + radix_mpath.
Bom dia alguem ja testou tabela fibs + radix_mpath no FreeBSD 8.0. -- Alessandro de Souza Rocha Administrador de Redes e Sistemas FreeBSD-BR User #117 Long live FreeBSD Alessandro, Estou tentando testar o radix_mpath, mas ainda não consegui pois quando subi as (duas) rotas comecei a ver vários pacotes pegando o caminho errado (utilizando a interface errada). Mas como era bem tarde e eu ainda precisava resolver outros problemas, acabei voltando para o uso de duas FIBs. No fim nem as FIBs funcionaram... Para resolver (se você utiliza o ipfw fwd para forçar os pacotes para o gateway da segunda FIB por exemplo) você precisa desabilitar o flowtable: sysctl net.inet.flowtable.enable=0 (demorei só um poquinho pra descobrir isso... :/) No momento eu já encontrei uma solução para o problema e agora estou tentando passar isso pra frente (ainda não sei ao certo como ou quando isso deve ser resolvido). Fica a dica para quem precisar utilizar FIBs no freebsd-8. E estou aguardando outra oportunidade para tentar levantar o radix_mpath de novo (já que o problema podia estar relacionado com esse outro bug ou não...). Estou tentando montar um ambiente de testes para fazer os testes em laboratório, mas antes preciso ressucitar meus cacarecos aqui (hardware velho)... []'s Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Informar que endereço IP de origem usar
Caro Estou fazendo um programinha cliente TCP/IP. A interface por onde os pacotes dele saem possui dois endereços IP. Gostaria de que quando ele fizer uma conexão TCP/IP com um servidor ele use o endereço IP alias. Alguem conhece alguma chamada de sistema que permita que eu informe que endereço IP de origem usar (sockets RAW não vale)? Obrigado! Otacílio, Se eu entendi direito, você esta procurando a função bind(2). Com ela você pode especificar o IP de origem de uma conexão (quando você tem mais de um IP na maquina, você consegue especificar a partir de qual deles a conexão vai partir). []'s - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] Fw: [FreeBSD-Announce] Be Counted!
Dear FreeBSD Community, Millions of systems run FreeBSD. Hundreds of volunteers contribute to FreeBSD's success. But what is the size of FreeBSD's user base? This simple question is very hard to answer, but its answer is vital to the cause of promoting FreeBSD. It is extremely difficult to convince businesses to invest time and money to add FreeBSD support to their products based solely on vague estimates of the size of our community. We should know - working to make FreeBSD a more widely supported platform is a task the FreeBSD Foundation has worked on since its inception. Please help us in our fight to promote FreeBSD. A donation to the FreeBSD Foundation helps fund our work, but it also gives us strength in numbers. Our count of unique donors is a vital indication of the size and buying power of our community. However, we have never broken even one thousand donors in any year. We know in our hearts that this is a small fraction of our user base and of those who want to help expand FreeBSD's presence. So stand up and be counted! Make a donation. Encourage other FreeBSD users to donate as well. No donation amount is too large or too small. Just by becoming a donor you are making a powerful statement about the strength of FreeBSD! You can make a donation by going to: http://www.freebsdfoundation.org/donate/. To find out more about The FreeBSD Foundation, please visit http://www.freebsdfoundation.org. Thank You, Justin T. Gibbs President and Founder The FreeBSD Foundation Desculpem o cross-posting, sei que muitos devem ter recebido... Mas essa é uma mensagem importante e interessante, pois como tento dizer por aqui, o importante é participar, como cada um pode ou como dito no e-mail: No donation amount is too large or too small. Ou seja se você tem um cartão de crédito internacional (ou uma conta no paypal) não há motivo para você não fazer a doação de 1, 5, 10, 50, 100 doláres (ou quanto for possível pra você). Vamos ser contados ? =) - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Rede windows server e freebsd
EU tenho uma rede onde tenho 2 controladores de domínio com wind 2008 server, que não poderei retirar. Porém esta rede possui alguns roteadores em Freebsd dividindo a rede em sub-redes. Inclusive tenho subredes com 3 níveis até chegar na subrede principal com AD no windows 2008. O netbios não está propagando entre as subredes, pois os clientes enviam requisições para o broadcast da subrede que não é repassada para a rede onde está os ADs. O roteadores com Freebsd não possuem filtro para broadcast, estes apenas não roteam broadcast. Alguém conhece alguma solução que eu possa fazer os roteadores BSD prara o clientes dass subredes falarem com os ADs. eu não tenho interfaces de redes nos Ads para colocar placas de rede extra e conectá=los as subredes. obs: o pessoal do win 2008 server não quer trabalhar com wins instalado nos win server 2008. Tenho que achar uma solução nos roteadores com freebsd. O samba possui alguma função parecida como proxy de AD? Alguém sabe como me ajudar? Anderson, Até onde me lembro isso é problema do windows server da vida, ele não aceita conexões de ips que estão em outra faixa de ips (ips diferentes dos configurados em suas interfaces). Tem um lugar no windows (que eu não consigo me lembrar agora) que você pode adicionar as subnets que devem ser aceitas (alem daquelas configuradas nas interfaces de rede). Pode levar o problema de volta para o pessoal do windows, pois no freebsd só mesmo fazendo nat =) Nas versões modernas (a partir do 2003) o uso de broadcast é limitado, a maior parte da rede funciona através do DNS (lá estão as informações sobre os servidores ldap, global catalogs e tudo mais que o cliente precisa). Eu rodo algumas redes windows utilizando isc-dhcp + bind (deu trabalho na primeira vez, mas nunca mais precisei perder tempo debugando problemas do DNS da MS - o dns estava com os dados no AD que precisa do dns pra funcionar... bizaro...). []'s - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Rede windows server e freebsd
A rede está roteada porque os limites físicos foram ultrapassados (cascateamento e distância entre cabeamento) e segurança. Pensei até em testar brigde ou outra opção. Sim nesse caso uma bridge resolve seus problemas de maneia bem simples. Basta por todo mundo na mesma classe de IP. []'s 2009/7/26 Luiz Otavio O Souza lists...@gmail.com EU tenho uma rede onde tenho 2 controladores de domínio com wind 2008 server, que não poderei retirar. Porém esta rede possui alguns roteadores em Freebsd dividindo a rede em sub-redes. Inclusive tenho subredes com 3 níveis até chegar na subrede principal com AD no windows 2008. O netbios não está propagando entre as subredes, pois os clientes enviam requisições para o broadcast da subrede que não é repassada para a rede onde está os ADs. O roteadores com Freebsd não possuem filtro para broadcast, estes apenas não roteam broadcast. Alguém conhece alguma solução que eu possa fazer os roteadores BSD prara o clientes dass subredes falarem com os ADs. eu não tenho interfaces de redes nos Ads para colocar placas de rede extra e conectá=los as subredes. obs: o pessoal do win 2008 server não quer trabalhar com wins instalado nos win server 2008. Tenho que achar uma solução nos roteadores com freebsd. O samba possui alguma função parecida como proxy de AD? Alguém sabe como me ajudar? Anderson, Até onde me lembro isso é problema do windows server da vida, ele não aceita conexões de ips que estão em outra faixa de ips (ips diferentes dos configurados em suas interfaces). Tem um lugar no windows (que eu não consigo me lembrar agora) que você pode adicionar as subnets que devem ser aceitas (alem daquelas configuradas nas interfaces de rede). Pode levar o problema de volta para o pessoal do windows, pois no freebsd só mesmo fazendo nat =) Nas versões modernas (a partir do 2003) o uso de broadcast é limitado, a maior parte da rede funciona através do DNS (lá estão as informações sobre os servidores ldap, global catalogs e tudo mais que o cliente precisa). Eu rodo algumas redes windows utilizando isc-dhcp + bind (deu trabalho na primeira vez, mas nunca mais precisei perder tempo debugando problemas do DNS da MS - o dns estava com os dados no AD que precisa do dns pra funcionar... bizaro...). []'s - 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 --- - 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] Controle de banda para lanhouse
Falou tudo sabixão... todos temos direito de expressar nossas opniões, porém aqui não é sua casa e nem um playground de crianças para respostas como a do seu amiguinho e os escrementos vindos de suas respostas fúteis. Estamos aqui discutindo métodos de como fazer um controle de banda para uma Lanhouse e não ensinando os bebêzões a trocar fralda ou mesmo descontar a raiva proveniente de seus distúrbios emocionais. Vocês com as suas arrogâncias não sabem perder uma resposta, isso é muito triste de saber, porém é nesse mundo que vivemos e temos que acostumar a viver com tipinhos igual a você. Como eu sei que pessoas do seu tipo sempre querem ter a última resposta, gostaria de te deixar mais animado, pois não irei responder mais nada. Anyway... G.F.Y. Da pra parar com essa falta de educação para com os membros da lista ? Nossos olhos não são pinico. No momento a unica coisa sendo discutida aqui é a idade de vocês. Se vocês não sabem o que é respeito pelos outros (algumas milhares de pessoas que assinam a listae não tem nada a ver com os seus desafetos), por favor vão discutir isso num ringue (vai rolar no próximo encontro na churrascaria). Grow up! Profissional... you must be kidding... Pessoas como o irado são a razão da força da nossa comunidade, são as respostas fúteis dele que ajudam pessoas (ao contrário das suas respostas sem noção). O irado manda nessa p***a toda, e ele consquistou isso com sabedoria e respeito, você pode impor suas soluções onde elas são bem vindas, não aqui. A quem não tem nada a ver com isso, desculpe. Só espero que essa thread termine aqui. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] balanceamento
Eu tenho dois links de 2M ligados em um servidor freebsd 7.2 fazendo balanceamento so que eu determino para cada IP para o link de deve navegar. Gostaria que isso fosse feito automaticamente dividindo o trafego por igual nesses links vi algumas soluções na NET minha duvida é se determinar que o trafego vai ser divididos de forma igual pelos links traz algum problema de conexão para os usuários. Estou usando o IPFW no balanceamento. Gelsimauro, O FreeBSD-8 possibilita que você adicione duas ou mais rotas default e os pacotes serão enviados utilizando round-robin. Eu já tenho um servidor pronto para ser instalado com essa configuração, mas isso só vai acontecer na semana que vem. Nessa instalação (2 links IP 1Mb cada, EBT e Telecomica) vou verificar os detalhes tipicos desse tipo de instalação e depois posso retornar para a lista como isso funciona. Os exemplos também serão baseados no ipfw. Abraços, Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] balanceamento
Múltiplas tabelas de roteamento está disponível desde a versão 7.1 do freebsd, porém é necessário compilar o kernel com a opção ROUTETABLES, e também deve ser especificado o número de tabelas que o kernel irá processar, que são no máximo 16. # cat /sys/conf/NOTES |grep ROUTETABLES options ROUTETABLES=2 # max 16. 1 is back compatible. Luiz Otavio O Souza escreveu: Eu tenho dois links de 2M ligados em um servidor freebsd 7.2 fazendo balanceamento so que eu determino para cada IP para o link de deve navegar. Gostaria que isso fosse feito automaticamente dividindo o trafego por igual nesses links vi algumas soluções na NET minha duvida é se determinar que o trafego vai ser divididos de forma igual pelos links traz algum problema de conexão para os usuários. Estou usando o IPFW no balanceamento. Gelsimauro, O FreeBSD-8 possibilita que você adicione duas ou mais rotas default e os pacotes serão enviados utilizando round-robin. Eu já tenho um servidor pronto para ser instalado com essa configuração, mas isso só vai acontecer na semana que vem. Nessa instalação (2 links IP 1Mb cada, EBT e Telecomica) vou verificar os detalhes tipicos desse tipo de instalação e depois posso retornar para a lista como isso funciona. Os exemplos também serão baseados no ipfw. Abraços, Luiz -- Atenciosamente, Danton Dorati http://www.freebsdbrasil.com.br Telefone/Fax: (31) 3516 0800 FreeBSD Brasil - FreeBSD Brasil LTDA Avenida Getulio Vargas, 54 - 3º andar Funcionarios - Belo Horizonte. Happiness is nothing more than good health and a bad memory. Bom dia Danton, Eu não estou falando de multiplas tabelas de roteamento (FIBs) e sim de multiplas rotas default na mesma tabela ! Eu já uso as FIBs a algum tempo e esse novo servidor vai justamente substituir um que já funciona via FIB (os dois links já estão balanceados - dentro das possibilidades das multiplas FIBs). No FreeBSD-8 você tem o a opção RADIX_MPATH que permite o uso de multiplas rotas para o mesmo destino (inclusive para o default gateway). att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] balanceamento
Luiz Otavio O Souza escreveu: Eu tenho dois links de 2M ligados em um servidor freebsd 7.2 fazendo balanceamento so que eu determino para cada IP para o link de deve navegar. Gostaria que isso fosse feito automaticamente dividindo o trafego por igual nesses links vi algumas soluções na NET minha duvida é se determinar que o trafego vai ser divididos de forma igual pelos links traz algum problema de conexão para os usuários. Estou usando o IPFW no balanceamento. Gelsimauro, O FreeBSD-8 possibilita que você adicione duas ou mais rotas default e os pacotes serão enviados utilizando round-robin. Eu já tenho um servidor pronto para ser instalado com essa configuração, mas isso só vai acontecer na semana que vem. Nessa instalação (2 links IP 1Mb cada, EBT e Telecomica) vou verificar os detalhes tipicos desse tipo de instalação e depois posso retornar para a lista como isso funciona. Os exemplos também serão baseados no ipfw. Abraços, Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Interessante Luiz! Lembro de ter visto um artigo sobre o FB8 mas não vi isso. Tenho alguma coisa com route-to do PF, mas é bem básico. O chato desse balanceamento com route-to é que se um dos links cair o round-robin continua mandando pacote para interface... pelo que li e vi os amigos comentando funciona assim... se bem que não vejo outra forma, só se ele pingasse o gateway e quando fosse detectado a a falta de resposta desativasse o envio para esta interface (se bem que gateway respondendo nem sempre significa internet funcionando =). Enfim, isso é assunto para os experts em HA =) Tenham um bom dia! -- Welkson Renny de Medeiros Focus Automação Comercial Desenvolvimento / Gerência de Redes welk...@focusautomacao.com.br Bom dia Welkson, Parece que esse é um daqueles recursos sem muita propaganda embora esteja no -current a bastante tempo (tenho a impressão que os gringos utilizam cada vez menos esse tipo de solução - ele utilizam muito bgp e ipv6 - então sobra para o 3o mundo testar...). historyEu não encontrei nada a respeito disso na net, tirando alguns e-mails aqui e ali com pouquissima informação util (para o usuário). Isso pulou na minha frente enquanto eu tentava entender as FIBs para tentar um pequena modificação./history O correto para detectar a falha do link via ethernet seria uma ethernet para cada link e configurar nos equipamentos (você já deve ter visto alguns dispositivos wireless com essa função) para desabilitar a ethernet no caso de falta de sinal. Assim com a ethernet down o pf (e qualquer outro sistema) poderia detectar que o link esta down e para de enviar dados nesse link. Infelizmente o link cai e a ethernet fica eu sei... :/ Com as multiplas rotas, um programa externo pode atuar como um router daemon e marcar a rota como down em caso de pane no uplink (como detectar a falha é outro problema...). Sim, (in)felizmente temos muito para avançar nessa area. []'s Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Fwd: FreeBSD 8.0-BETA1 Available
Não vi referencia a prometida multiplas rotas default(s) e sobre a esperada facilidade de virtualizaçãotento etc e tal conforme descrito no link : http://ivoras.sharanet.org/freebsd/freebsd8.html []'s Marcello, Veja se é isso que você esta procurando.. server# setfib 1 route add default 192.168.0.254 add net default: gateway 192.168.0.254 server# setfib 1 route add default 192.168.0.253 add net default: gateway 192.168.0.253 server# setfib 1 netstat -rn Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire default192.168.0.254 UGS 00rl0 = default192.168.0.253 UGS 00rl0 127.0.0.1 link#4 UH 00lo0 192.168.0.0/24 link#1 U 00rl0 xxx.xxx.xxx.242link#5 UH 00 tun0 Internet6: Destination Gateway Flags Netif Expire ::1 ::1 UH lo0 fe80::%lo0/64 link#4U lo0 ff01:4::/32 fe80::1%lo0 U lo0 ff02::%lo0/32 fe80::1%lo0 U lo0 ff02::%tun0/32fe80::208:54ff:fe0e:5577%tun0 UGS server# uname -a FreeBSD server.rede.int.br 8.0-CURRENT FreeBSD 8.0-CURRENT #0 r194962M: Fri Jul 3 14:37:48 BRT 2009 r...@server.rede.int.br:/usr/src/sys/i386/compile/FW i386 * usei a FIB 1 apenas para exemplo e para não estragar o meu roteamento que esta na FIB 0 (para a tabela default basta remover o comando setfib(1)). Para ativar esse suporte a multi-rotas você precisa adicionar options RADIX_MPATH no seu kernel. Estou com um servidor pronto para testar isso (sim, só fiz alguns testes de laboratório, agora vai pra produção !). A instalação deve ser marcada na próxima semana (dependia de um switch que chegou ontem). A virtualização esta quase pronta (pelo pouco que sei, essa eu nunca testei), existem patchs para você testar se quiser. Não tenho certeza se isso será integrado a tempo do 8.0, mas o recurso deve ficar pronto ainda para a série 8. Abração, Luiz PS: Cade aquela puma ? =) PS2: Agora sim vou precisar voltar a beber... fibs + radix_mpath... wow ;) - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] FreeBSD 8.0 + Lusca
Olá, pessoal. No FreeBSD 8.0 com o Lusca, o suporte a tproxy já vem embutido? Não precisamos de patches pra fazer funcionar? - -- João Paulo Just Diretor Executivo Justsoft Informática Ltda. - http://www.justsoft.com.br/ FCP - Furukawa Certified Professional - -- Feira de Santana, BA, Brasil. +55 75 8104 8473 Blog: http://just.rg3.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org Bom dia João Paulo, SIM ! (e não!) Você precisa só editar um arquivo no lusca: libiapp/comm_ips_freebsd.c e mudar onde esta escrito IP_NONLOCALOK para IP_BINDANY Pronto, você não precisa de mais nada =) Como o uso do FreeBSD-8 ainda é pequeno essa mudança não foi levada a sério. Em breve a alteração estará no svn do lusca. Abraços, Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] SSH Rumors
http://isc.sans.org/diary.html?storyid=6742 Comentários? -- Welkson Renny de Medeiros Focus Automação Comercial Desenvolvimento / Gerência de Redes welk...@focusautomacao.com.br Welkson, Sem comentários (aguardando mais notícias sobre o fato)... segue apenas o e-mail que provavelmente causou o _panico_: http://seclists.org/fulldisclosure/2009/Jul/0028.html Cuidado com o que se fala ;) []'s Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] RES: tproxy/cacheboy
Renato Fiz testes com o cacheboy 1.6 e lusca-head, ambos funcionaram porém notei lentidão para navegar. Pode ser a máquina ou tunning, não sei, preciso testar as possibilidades. Ainda não consegui instalar o squid 3.0, conforme o howto em http://tproxy.no-ip.org/. Sabe dizer qual é a versão exata naquela instalação? No meu ports está a 3.0.16. Segue o erro nesta versão: make all === Vulnerability check disabled, database not found === Found saved configuration for squid-3.0.16 === Extracting for squid-3.0.16 = MD5 Checksum OK for squid3.0/squid-3.0.STABLE16.tar.bz2. = SHA256 Checksum OK for squid3.0/squid-3.0.STABLE16.tar.bz2. = MD5 Checksum OK for squid3.0/b9052.patch. = SHA256 Checksum OK for squid3.0/b9052.patch. === squid-3.0.16 depends on file: /usr/local/bin/perl5.8.9 - found === Patching for squid-3.0.16 === squid-3.0.16 depends on file: /usr/local/bin/perl5.8.9 - found === Applying distribution patches for squid-3.0.16 === Applying extra patch /usr/ports/www/squid30/files/freebsd-tproxy-squid.patch 1 out of 1 hunks failed--saving rejects to src/http.cc.rej *** Error code 1 Stop in /usr/ports/www/squid30. *** Error code 1 Stop in /usr/ports/www/squid30. (...) abraços, Daniel Daniel, Hmm.. Atualizei o patch do squid aqui no site (http://tproxy.no-ip.org). Agora ele compila sem mágica =) Obrigado a você e ao Renato pelos testes. []'s Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] tproxy/cacheboy
Pessoal, Desde a disponibilização do patch tproxy+cacheboy pro freebsd eu estou usando sem problemas. Porém de 3 dias para cá esta mensagem aparece repentinamente e só reiniciando o squid que volta: TPROXY comm_ips_bind failed? Why? Vocês tem alguma idéia? Aumentar alguma sysctl? Renato, Foi encontrado um bug no lusca que pode eventualmente causar esse erro. O erro encontrado acontece sempre que há um erro na conexão com o servidor e o lusca precisa fazer uma segunda tentativa (dai o bind to tproxy falha). Por favor atualize para o lusca head que contém um workaround para esse problema (ainda não pode ser considerado uma solução final, mas deve evitar que esse problema especifico volte a acontecer). Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] tproxy/cacheboy
Pessoal, Desde a disponibilização do patch tproxy+cacheboy pro freebsd eu estou usando sem problemas. Porém de 3 dias para cá esta mensagem aparece repentinamente e só reiniciando o squid que volta: TPROXY comm_ips_bind failed? Why? Vocês tem alguma idéia? Aumentar alguma sysctl? Renato, Eu dei uma revisada no código e encontrei apenas um ou dois pontos que podem produzir esse erro, mas a causa ainda é desconhecida (precisamos de mais informações para rastrear). Verifique se não há qualquer outra informação nos logs do lusca (cache.log ?) e também nos logs do servidor (messages, all.log). Os ctls que você tem que monitorar são esses: kern.ipc.maxsockets: 25600 kern.ipc.numopensockets: 101 kern.maxfiles: 65536 kern.maxfilesperproc: 11095 kern.openfiles: 258 A falta de sockets ou file descriptors podem causar esses erros, então fique atento. Se o problema persistir, por favor me avise. Att., Luiz PS: Veja esse link com o lusca+tproxy COM FreeBSD fazendo proxy de um link de satelite de 100Mb/s - cute ;) http://lusca-cache.blogspot.com/2009/06/lusca-head-pushing-100mbit-in.html - 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: RES: tproxy/cacheboy
Renato. Acabei de fazer o que vc disse e está ocorrendo um problema com 'IP_NONLOCALOK'. O kernel já está compilado com os patches, porém, não sei como ver se está iniciado ou não, já que no dmesg ele não aparece ... Alguma dica? Obrigado. c -DHAVE_CONFIG_H -I. -I../include -O2 -fno-strict-aliasing -pipe -D_REENTRANT -MT comm_ips_tproxy2.o -MD -MP -MF .deps/comm_ips_tproxy2.Tpo -c -o comm_ips_tproxy2.o comm_ips_tproxy2.c mv -f .deps/comm_ips_tproxy2.Tpo .deps/comm_ips_tproxy2.Po c -DHAVE_CONFIG_H -I. -I../include -O2 -fno-strict-aliasing -pipe -D_REENTRANT -MT comm_ips_tproxy4.o -MD -MP -MF .deps/comm_ips_tproxy4.Tpo -c -o comm_ips_tproxy4.o comm_ips_tproxy4.c mv -f .deps/comm_ips_tproxy4.Tpo .deps/comm_ips_tproxy4.Po c -DHAVE_CONFIG_H -I. -I../include -O2 -fno-strict-aliasing -pipe -D_REENTRANT -MT comm_ips_freebsd.o -MD -MP -MF .deps/comm_ips_freebsd.Tpo -c -o comm_ips_freebsd.o comm_ips_freebsd.c comm_ips_freebsd.c: In function 'comm_ips_bind': comm_ips_freebsd.c:27: error: 'IP_NONLOCALOK' undeclared (first use in this function) comm_ips_freebsd.c:27: error: (Each undeclared identifier is reported only once comm_ips_freebsd.c:27: error: for each function it appears in.) *** Error code 1 Stop in /usr/ports/www/cacheboy16/work/cacheboy-1.6-r13601/libiapp. *** Error code 1 Stop in /usr/ports/www/cacheboy16/work/cacheboy-1.6-r13601. *** Error code 1 Stop in /usr/ports/www/cacheboy16. *** Error code 1 Stop in /usr/ports/www/cacheboy16. Daniel, Siga o site http://tproxy.no-ip.org e você não terá problemas... Faltou você copiar o header (retirado do site): a.. Install the new kernel and reboot the server a.. Update the in.h header: # cp /usr/src/sys/netinet/in.h /usr/include/netinet E por favor utilize o lusca HEAD essa versão do ports é muioo antiga. Para baixar o lusca head, por enquanto, só pelo svn (/usr/ports/devel/subversion-freebsd): svn http://lusca-cache.googlecode.com/svn/branches/LUSCA_HEAD lusca-head No lusca head, você terá algumas novidades, mas a principal é que você terá suporte a apenas aufs e coss (diskd foi removido !) e por conta de um bug descoberto recentemente (ainda sem correção e provavelmente também presente no squid) não é recomendado utilizar mais do que um tipo de armazenamento no mesmo proxy (aufs + coss) até que o problema seja resolvido (caso contrário você verá alguns bugs aleatórios e esporádicos). []'s Luiz - 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: RES: tproxy/cacheboy
Ainda em tempo: alguém já conseguiu utilizar o tproxy/lusca no Freebsd em bridge ? Abraço! Eduardo, No freebsd não conhecemos ninguem que testou, quem sabe você não pode nos ajudar a testar =) Pode ser que o ipfw faça tudo que seja preciso (direcionamento, roteamento, etc, etc), pode ser que seja necessário desenterrar aquele pedaço de código que ninguem sabia pra que servia ;) []'s Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Bandwidthd com processos defunct
pessoal instalei o bandwidthd e estou usando o arquivo bandwidthd.conf para configuração padrão do mesmo, estou reiniciando a cada 5 min pelo cron */5 * * * * kill -HUP `cat /var/run/bandwidthd.pid` já tentei a mesma linha acima com killall -HUP bandwidthd no entanto, a cada vez que o HUP reinicia os processos do bandwitdthd, vai acumulando processos zombies, porém, os gráficos são gerados corretamente alguém sabe o que pode estar causando isso -- ENIO RODRIGO MARCONCINI www.Enio.Pro.Br skype: eniorm Enio, Isso é um bug do bandwidthd, quando você faz um fork(2) (cria um processo filho), as opções padrão vão fazer que esse filho ao morrer (terminar o seu serviço, terminar por conta de um problema) deixe o seu status para o processo pai consultar e saber se o processo ainda esta sendo executado ou se se já terminou e com qual status. Se o processo filho morre e o processo pai não le esse status (wait(2)) o processo filho fica como zumbi. Tirando o monte de zumbis que você ve ai (e alguma memória que isso consome) esse problema em si, não causa maiores danos. Agora a pergunta que não quer calar... por que você envia um SIGHUP a cada 5 minutos para o bandwidthd ? []'s Luiz - 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: Nat para tunnel IPSEC
Na verdade é net-to-host eu tenho uma /29 aqui que acessa um /32.. Apenas isso, nada mais... O que acontece aqui, é que lidar com banco eh uma m%$%#$^... Ai eles me deram a diretriz que eu preciso fazer nat de todas as outras maquinas da minha /29 para o ip final 1. Entendeu o meu drama.. Bom dia Tiago, O OpenBSD usa vpn dessa maneira (sem gif - http://www.openbsd.org/cgi-bin/man.cgi?query=vpnapropos=0sektion=0manpath=OpenBSD+Currentarch=i386format=html - muito bom esse manual) E eu fiz uma vez uma VPN FreeBSD OpenBSD e precisei fazer alguma coisa parecida com o que você esta tentando, eu criei a interface gif no FreeBSD (para poder adicionar a rota) e funcionou bem, sem maiores problemas (problema maior que IPSEC é dificil =)). Outra alternativa é você criar/usar uma interface enc onde você deve ter acesso a todos os pacotes que vão para o tunel e ali quem sabe, fazer o nat que você precisa. Abraços, Luiz PS: O bot mandou um recado: 97721255 - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] PHP dando segfault
Em Tue, 9 Jun 2009 08:23:03 -0300 Thiago J. Ruiz thiagojr...@gmail.com, conhecido consumidor de drogas (BigMac's com Coke) escreveu: me corrijam se estiver errado mas fault 11 não é erro de memória física? normalmente, sim. Cabe um bom stress no hardware APÓS limpeza de contatos/slots, essas coisas. Tiago e Irado, Normalmente NÃO :) Esse é o famoso segmentation fault (11) e acontece sempre que você tenta acessar ou usar uma memória que não esta alocada para você (em programas C ou outras linguagens que permitem isso). Coisa do tipo você aloca 10 bytes e tenta escrever 11 ou mais bytes, ou seja, isso é normalmente um bug e nesse caso acontece sempre no mesmo local e no freebsd gera um core que da pra você debugar. Nos casos de defeito de memória o problema acontece aleatoriamente (um programa executa uma vez e na vez seguinte da o erro), todo e qualquer programa no sistema pode ser afetado, mesmo os que funcionavam bem. Um dos melhores testes de hardware que conheço é o make buildworld, a maior parte dos hardwares com algum tipo de defeito que já vi, não consegue compilar o sistema. Sobre a pergunta original do Leonardo, eu tive esse problema no php depois de compilar o suporte ao postgres (na época tinha que alterar uma opção no port do client do postgres), não sei se é esse o seu caso. Isso também pode acontecer se você atualizou seu sistema e modificou alguma lib que é utilizada pelo php, nesse caso pode ser que você precise recompilar o php e seus módulos. Att., Luiz - 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: Usar dois links de internet
Galera, E o seguinte pretendo adicionar mais um links de internet, já tenho um com IP dedicado para minha VPN e deseja adquirir um de banda larga (velox). usar somente para navegação. Eu uso o pfsense para este caso As minhas maquinas que tenho disponível são todas da Dell e as mesmas só tem uma placa de rede on-board e um slot de PCI para placa de rede off-board. Se tivesse condições de colocar outra placa de rede eu não teria problemas de fazer esse roteamento acontece que não tenho devido a limitação dos computadores da Dell, somente com um slot de expansão. Alguem sabe outra solução que não seja adicionando uma nova placa de rede ? se adicionar um Alias na segunda placa será que funciona para fazer esse roteamento em direcionar o link velox somente para navegação ? Cristina Acho que não. O NAT daria para fazer o bind no IP, não na interface, não tem problema. Porem as regras de divert normalmente faz com a interface, para o trafego que volta do Nat, e o velox tem IP dinâmico, então não sei se daria. De qualquer maneira, compre uma placa USB, veja a discussão[1] que já rolou aqui. Pelo preço[2] vale a tentativa, se não der, você tem mais uma placa ethernet para ligar em seu notebook e fazer bridge, hehe :) [1]: http://www.fugspbr.org/historico/html/freebsd/2009-05/msg00529.html [2]: http://produto.mercadolivre.com.br/MLB-94860299-mini-placa-de-rede-usb-ethernet-10100-adapt-frete-gratis-_JM Sim o Renato tem razão, fazer dois nats na mesma interface pode ser uma dor de cabeça... Agora quanto ao problema, caso você tenha um switch melhorzinho, você pode utilizar vlans, assim da sua placa você faz duas, tres ou quantas precisar, se for gigabit então, problema resolvido =) Alias, o 8 esta com algumas alterações nessa parte (multi-path) que parecem ser bem interessantes, vamos aguardar ! =) []'s Luiz - 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: Cache de P2P
A complexidade dos P2P hoje em dia, em minha opinião, é demais para que alguém tenha tido tempo e vontade para fazer uma solução e colocá-la gratuita. Para fins de comparação, as soluções discutidas da GTER para P2P, se formos comparar valores com soluções de cachê HTTP, que também foram discutidas lá a alguns meses é muito mais alto. Ou seja, até as soluções comerciais atualmente ainda nao são acessíveis como os cachê HTTP profissionais. Então Renato. É mais que certo que vou comprar este tipo de equipamento, porém qual dos produtos é o mais confiavel é o que me preocupa. Se tivesse uma solução opensource eu poderia testar e se não desse certo descataria ja que tive apenas custo técnico para implementa-lo. Se alguem na lista for revendedor ou utiliza este tipo de solução por favor entre em pvt comigo. Matheus, Pelo que foi comentado no GTER e pelo que encontrei na web, parece que esse tipo de aplicação é bem interessante e nem tão dificil assim de ser implementado (para torrents). O acesso aos trackers é feito via http e é ai que se faz o controle ou que se insere a informação que se quer (o endereço do seu cache/seeder por exemplo), depois tudo corre normalmente, no máximo você altera seu seeders para não armazenar arquivos completos, como faz aquela tal operadora. Agora, dados os custos dos equipamentos que fazem isso hoje, acho dificil encontrar algo parecido open-source (pelo menos enquanto isso é novidade). []'s Luiz - 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: RES: Proxy com IP Válido
Não sei do site oficial, o que eu tenho é que o que foi discutido na
lista.
De qq maneira, botei em meu site, fica fácil para todo mundo pegar
HTTP://www.dahype.org/freebsd/tproxy
Lembrando que o patch para o squid só é necessário se usar o squid30. Para
o cacheboy, basta no make config escolher tproxy.
Tem um readme lá com a receita de bolo :-)
Tem alguem usando o tproxy com o freebsd-stable (7.x) ?
Alguem pode/gostaria de testar a nova versão para stable ?
O patch esta aqui: http://loos.no-ip.org/downloads/ip_bindany_stable.patch
A antiga opção IP_NONLOCALOK foi renomeada para IP_BINDANY que é mais
parecida com a opção do OpenBSD SO_BINDANY. Também não é mais preciso
adicionar a opção no kernel para habilitar isso nem mesmo ativar via sysctl.
Recomendo que isso seja testado com o lusca head:
svn checkout http://lusca-cache.googlecode.com/svn/branches/LUSCA_HEAD/
lusca
Será preciso fazer essa alteração no lusca para que o mesmo possa compilar:
--- libiapp/comm_ips_freebsd.c.orig 2009-06-08 10:01:02.0 -0300
+++ libiapp/comm_ips_freebsd.c 2009-06-08 10:01:16.0 -0300
@@ -24,7 +24,7 @@
{
int on = 1;
-if (setsockopt(fd, IPPROTO_IP, IP_NONLOCALOK, (char *)on, sizeof(on))
!= 0)
+if (setsockopt(fd, IPPROTO_IP, IP_BINDANY, (char *)on, sizeof(on)) !=
0)
return COMM_ERROR;
if (bind(fd, sqinet_get_entry(a), sqinet_get_length(a)) != 0)
return COMM_ERROR;
Se alguem testar não deixe de reportar como foi.
Qualquer duvida e/ou sugestão, estou a disposição.
Grato,
Luiz
PS: Você vai precisa do 7-stable atualizado para aplicar este patch
-
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: RES: Proxy com IP Válido
Não sei do site oficial, o que eu tenho é que o que foi discutido na
lista.
De qq maneira, botei em meu site, fica fácil para todo mundo pegar
HTTP://www.dahype.org/freebsd/tproxy
Lembrando que o patch para o squid só é necessário se usar o squid30. Para
o cacheboy, basta no make config escolher tproxy.
Tem um readme lá com a receita de bolo :-)
Tem alguem usando o tproxy com o freebsd-stable (7.x) ?
Alguem pode/gostaria de testar a nova versão para stable ?
O patch esta aqui: http://loos.no-ip.org/downloads/ip_bindany_stable.patch
A antiga opção IP_NONLOCALOK foi renomeada para IP_BINDANY que é mais
parecida com a opção do OpenBSD SO_BINDANY. Também não é mais preciso
adicionar a opção no kernel para habilitar isso nem mesmo ativar via sysctl.
Recomendo que isso seja testado com o lusca head:
svn checkout http://lusca-cache.googlecode.com/svn/branches/LUSCA_HEAD/
lusca
Será preciso fazer essa alteração no lusca para que o mesmo possa compilar:
--- libiapp/comm_ips_freebsd.c.orig 2009-06-08 10:01:02.0 -0300
+++ libiapp/comm_ips_freebsd.c 2009-06-08 10:01:16.0 -0300
@@ -24,7 +24,7 @@
{
int on = 1;
-if (setsockopt(fd, IPPROTO_IP, IP_NONLOCALOK, (char *)on, sizeof(on))
!= 0)
+if (setsockopt(fd, IPPROTO_IP, IP_BINDANY, (char *)on, sizeof(on)) !=
0)
return COMM_ERROR;
if (bind(fd, sqinet_get_entry(a), sqinet_get_length(a)) != 0)
return COMM_ERROR;
Se alguem testar não deixe de reportar como foi.
Qualquer duvida e/ou sugestão, estou a disposição.
Grato,
Luiz
PS: Você vai precisa do 7-stable atualizado para aplicar este patch
-
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: RES: Cache de P2P
Exato Luiz, difícil não é, teoricamente. O problema é fazer isto em escala de tráfego de ISP e o processamento, afinal abrir a conexão até o L7, reempacotar, entregar o arquivo, salvar em disco e etc, o OS tem que estar bem otimizado para funcionar de acordo :) Eu já assisti sobre solução da peerapp, chamado ultraband. Inclusive faz cachê de youtube e afins. Eles estiveram na futurecom 2008. É um servidor Dell com o sistema operacional da peerapp rodando. Talvez atenda suas necessidades, mas nem tenho idéia de valores. Mas por rodar em um PC normal teoricamente já é um pouco mais barato que aqueles que fazem uma caixa preta.. Renato, Essa é a vantgem de interceptar o acesso ao tracker nos torrents, você não precisa ficar inspecionando cada conexão do cliente, muito menos reempacotar nada =) Você só intercepta e altera as conexões (http) feitas ao tracker no resto você não precisa mexer. Isso é feito via proxy http (lusca - squid) e porisso a mesma solução também faz cache de videos do youtube (na lista do lusca você encontrará algumas configurações bem interessantes de alguns usuários que fazem o cache de videos e algumas outras coisas - se não me engano tem um post do Faysal com alguns exemplos). Enfim você só precisa dizer para o cliente que esta acessando o tracker que o único (ou uns dos únicos seeders para aquele arquivo) é o seu cache local. pronto problema resolvido (nem precisou quebrar criptografia nem nada disso). Outro motivo para acreditar que isso não é tão complicado é o uso de um hardware simples como você citou. Não se deixe enganar por essa conversa de SO peerapp (você deve ter uma idéia de quantas pessoas se precisa e de quanto deve custar fazer um SO), pode ter certeza que não é nada mais que um linux/bsd alterado (existe razão hoje em dia - tirando os doidos - para se escrever um SO do zero ?). Abraços, Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [off] mudou a internet, mudei eu..
(...) Finalmente, tenho que admitir que muitas, muitas vezes me sinto mal por não dedicar mais tempo à comunidade, à lista e à projetos envolvendo BSD. Não posso dar a desculpa de tempo porque é algo que ninguém tem por aqui, com certeza. +1 (...) Um forte abraço a todos, e nos vemos no FISL!! Precisava ser tão longe ? =) Eita Brasil sem porteiras... Eu gostaria muito de estar presente neste evento, mas acho que não terei condições para fazer essa viagem (tempo apertado, $$$ não ajuda, distancia muito menos). Mas que esse seja mais um grande evento em favor do FreeBSD e dos membros da comunidade que lá estarão. Grande abraço a todos, Luiz - 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: (não sei se é off) Priori zação de tráfego para dois hosts em PFSENSE
Matheus, Uma dúvida, que ainda não me ficou clara até hoje. Como você mesmo falou, eu posso criar no ipfw um pipe de 1MB para SSH e 30MB para web, mesmo que o link seja de 5MB. Não tem que ter nada próximo com a realidade, a não ser que você vá colocar pesos. No PF isto não é válido, eu tenho que criar uma classe com meu link total e ir divindo de forma que a soma não ultrapsse o total. Tem alguma outra maneira de fazer isto? Por exemplo, se você é um ISP e tem 100 usuários comprando 500K, não indica necessariamente que você tem um link de 5MB. E por aí vai. Ou outro exemplo, se eu tenho o PF em meu gateway e eu tenho a DMZ e quero limitar um PC a fazer downloads a 100K na internet, mas não limitar a DMZ, no PF eu teria que criar uma declaração para a DMZ, presumindo que o link seja a 100MB, outra para a internet e por ai vai. No ipfw eu faria um 'pipe X all from $pc_interno to $dmz out via ' e por ai vai. Renato, Eu não conheco a fundo o altq, mas o que entendo sobre esse assunto é o seguinte: O altq tem dois diferenciais quando comparado ao dummynet, ele pode ser programado para garantir a banda de um cliente (1Mb máximo com garantia mínima de 200Kb por ex.) e eventualmente uma classe pode emprestar a banda de outra classe que não esteja fazendo uso da sua parte. Para fazer isso só existe uma maneira, saber exatamente qual é a banda disponível para se trabalhar, só assim você consegue garantir que a limite mínimo será respeitado. Já no dummynet os pipes e queues não interagem um com o outro (são completamente independentes) e por isso não há o conhecimento por parte do sistema da banda real disponível e não há como garantir um mínimo de disponibilidade. Por esse motivo são normalmente utilizados como hard limit. Talvez (só talvez) o altq devesse fazer a conta das classes pelo limite mínimo e não máximo (para bater com a banda total disponível), ou ainda aceitar de alguma maneira a criação de classes dinâmicas de acordo com a necessidade (assim vc não precisa configurar as classes de 500 clientes, elas seriam criadas e removidas de acordo com a necessidade), mas enfim esse é só um comentário de quem acompanha esse assunto meio que de longe. A parte boa é que o FreeBSD conta com os dois sistemas e só fica limitado pela sua imaginação e vontade de fazer algo diferente =) Enfim estes são só meus 2 cents... []'s Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [OFF-TOPIC] Como ganhar dinheiro escrevendoOpen-Source?
Vendendo projetos de implementação e prestando suporte ? Alem destas opções obvias muitas empresas criam versões limitadas de seus softwares que distribuem de forma gratuita, e criam features avançadas pelas quais o usuário tem que pagar se quizer ter acesso. Edson 2009/5/27 Otacílio de Araújo Ramos Neto otacilio.n...@ee.ufcg.edu.br: Caros. Isto é algo que sempre quis saber mas tinha vergonha de perguntar. Queria saber dos colegas como eu posso ganhar dinheiro escrevendo Open-source. Srs., Eu acho que há uma confusão aqui... Não se escreve um software por escrever, sem um objetivo, sem um problema a ser resolvido, sem um nicho de mercado para se atender... Assim todo software que hoje é open-source, eu pessoalmente acredito que nasceu de uma necessidade comercial de alguem, que escreveu o software para atender a um ou mais clientes, mas que depois disso a pessoa, muitas vezes com um software muito bom nas mãos, acaba abrindo o código para não perder o programa (sim programas guardados no fundo do guada-roupa são comidos pelas traças). Programas precisam de constante desenvolvimento, correções e novas features para se manter em forma (e as vezes para se manter funcionando) e isso muitas vezes custa caro (tempo, analise e mesmo dinheiro) e o open-source muitas vezes supri parte ou todas essas necessidades. Por outro lado, depois de certo tempo o open-source começa a abrir (pequenas) portas pra você, você tem/pode ter seu trabalho reconhecido e mesmo alguns convites inexperados (participação em outros projetos, doações, muio contatos! e até mesmo oportunidades de emprego). Outra possibilidade é o desenvolvimento de soluções onde a empresa que compra o serviço (que muitas vezes nem opera no segmento de TI) precisa apenas da solução para determinado problema e você pode desenvolver, melhorar e/ou corrigir algum open-source sendo pago para fazer isso (aqui, acredito eu, se encaixam a maior parte dos trabalhos realizados pelos desenvolvedores open-source). Assim, acredito, ninguem vive de escrever código open-source, mas sim dos beneficios que esse modelo de negocio apresenta. Abraços e boa semana a todos, Luiz PS: claro que estou relatando o pouco que vejo e conheço desse mercado (devem existir muitas outras possibilidades mundo a fora) - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [OFF-TOPIC] Como ganhar dinheiro escrevendoOpen-Source?
Otacilio, Vamos lá, in line dessa vez... Um software sem um objetivo, sem um problema e sem um nicho eh só um monte de printf um atrás do outro. Mas acredito que tem gente que escreve código porque gosta mesmo. É só lembrar da primeira versão do kernel do Linux. Não que o cara vá escrever um software para nada, escreve porque precisa e porque gosta mas onde poderia usar uma solução paga também. É claro que tem gente que escreve software porque gosta, mas dai o cara tem um emprego para pagar as contas do mês e escreve software nas horas vagas, é como você comentou, um hobby, não mais do que isso. Realmente se faz muito software open-source na faculdade (para colocar em pratica aquilo que se aprende), mas dificilmente você ve esses softwares sobreviverem os 5 anos depois do termino da faculdade, pq ? Porque como comentei software parado se desatualiza e não tem mais utilidade e manter um software custa e custa muito tempo e dinheiro (o pessoal na faculdade muitas vezes tem parte do seu tempo disponível - até as contas começarem a chegar...). Agora viver dos benefícios eh o que eu acho complicado. É só olhar para Sun, com o java, netbeans, eclipse, mySQL e sendo comprada pela Oracle. Não acho que o exemplo da sun seja válido, não sabemos se os problemas dela são todos por conta do open-source (que eu saiba o negócio da sun são os diversos hardwares que ela fabrica e vende). O próprio MySQL nunca foi totalmente livre, sempre existiu a versão comercial, paga com recursos extras e a licença (a antiga pelo menos) não permitia o uso do MySQL open-source para aplicações comerciais (que nunca era respeitada). As coisinhas que faço para o opensource eu faço sem expectativa de retorno financeiro. Faço porque gosto. Gosto de ver as coisas compilando, linkando, juntando um monte de software diferente para formar um grande sistema. Mas faço isso como hobby. Agora, trabalhar sem cobrar e ainda esperar retorno financeiro por isso eu só vejo esse tipo de coisa com o pessoal de computação (sem querer ofender). Pode ter certeza que ninguem trabalha de graça, nem relógio! E esperar retorno pelo que se fez de graça é burrice ;) Para mim o opensource existe porque tem tanta matéria prima no mundo (cérebro e computador) e tanto fornecedor (programador) que o preço caiu tanto que virou opensource. Para o cara escrever um software para o pessoal de TI precisa dos programadores, dos computadores e do conhecimento. O conhecimento em informática é muito barato de conseguir (um boy saindo da faculdade escreveu um kernel de SO) e se dá problema é muito barato consertar (faz um patch e roda novamente). Concordo que uma das razões do opensource é o excesso de matéria prima (conhecimento) que precisa de uma maneira de se expressar além daquela na qual você é obrigado a produzir (no seu trabalho por exemplo). A maior parte dos desenvolvedores não estão desenvolvendo algo que gostariam, mas como bons funcionários cumprem com as suas obrigações para com os seus contratantes. E nesse caso o opensource é a valvula de escape para o que se quer. Agora não concordo que esse excesso barateou o custo da tecnologia a esse ponto, o windows por exemplo, continua custando caro (pra mim) e assim também todos os serviços profissionais de TI (se as empresas continuam pagando caro pelo windows, porque não pagar bem os outros serviços de TI ?). Embora eu conheca quem, como você citou, criou um pequeno SO na faculdade, isso são apenas exemplos e servem para demonstrar conhecimentos especificos (assembler, sistema de boot, sistema de arquivos) e nunca vi isso se tornar em nada mais util do que isso, até porque não passam de exemplos e os envolvidos detem apenas parte do conhecimento realmente necessário para um sistema desse tipo. Isso fica claro no desenvolvimento do FreeBSD, você vê hackers dos mais diversos tipos e nenhum deles detem o conhecimento total sobre o sistema, cada área conta o expertise de um (ou alguns) desenvolvedor(es) em especial. Agora em engenharia, onde alguém precisa ser responsabilizado quando a máscara do circuito VLSI de 1milhão de dólares tem uma falha, o avião cai ou a barragem estoura, aí sim pessoas precisam ser responsabilizadas pelas falhas e fica complicado usar um negócio que nas primeiras linhas fala que use sob sua conta e risco. Tudo bem, tem muita coisa boa ( FreeBSD :) ) mas vai explicar isso para um acionista que só entende e só está preocupado em ganhar dinheiro. O que conta para as empresas não é o nome do software (ou a licença - primeiras linhas) mas sim a sua funcionalidade e é por isso que existem sistemas opensources reconhecidos, não por ser de graça, mas por funcionar (e muito bem) assim como acontece com o FreeBSD. Quando você poe esse use por sua conta e risco isso é na verdade a sua proteção, para evitar que você seja processado quando a barragem se romper porque o email de aviso foi bloqueado no sistema que você desenvolveu.
Re: [FUG-BR] FreeBSD + Asterisk + E1
Isso éh até um pouco triste pra mim. Pesquisei um pouco sobre asterisk pra instalar aki na empresa. Eu acho isso triste para todos nós usuários de FreeBSD que simplesmente ficamos sem opção... Para funcionar em FreeBSD eu nao achei garantia fora das placas da digium. E sendo placas da digium, o seu link é ISDN? (aki pra pra mim isso eh sonho) se não for pode (obs: não estou afirmando nada) ter problemas, pois terá que usar o OpenR2, unicall, o que hoje não é 100% se tratando de digium, lah eh ISDN neh. Me parece (só parece, nunca testei...) que as digium já funcionam bem com R2, mas isso também é em Linux, no FreeBSD o zaptel parece que ainda esta bugado. Diante da dúvida (por causa da inexperiência, incerteZa e talz), eu fui obrigado a escolher a Debian. Isso porque fiz um curso na http://www.digivoice.com.br, com Alexandre Keller ( http://www.asteriks.com.br) e tive a triste certeZa que a digivoice não tem se quer pretenção de fazer seus drivers compatíveis com FreeBSD, e na ocasião as outras placas (intelbras, etc) também nao tinham driver para FreeBSD. Eu já mandei um e-mail de contato para a digivoice sobre a possibilidade de se portar o driver do linux para o FreeBSD, mas a ausencia de resposta me disse exatamente isso (eles não tem interesse). Até aqui tudo bem, basta eles continuarem com seus drivers abertos e nós (comunidade) na medida do possível fazemos a nossa parte. Infelizmente o FreeBSD perdeu alguns colaboradores nessa área e agora o zaptel é orfão de pai e mãe, embora tenham me dito que um russo estava trabalhando no port do dahdi para o FreeBSD (substituindo o zaptel bugado), mas isso já faz algum tempo e não vi mais notícias nesse sentido. O trabalho de port desses drivers é complexo, chato e requer muito tempo e atenção (sem falar na necessidade de se ter o hardware em mãos e as incontaveis horas de testes). Como a esperança é a ultima que morre, ainda tenho esperança de quem sabe conseguir algum $incentivo$ para trabalhar no port dos drivers, seria muito bom poder contar com esse hardware no nosso SO preferido. Sinceramente, não tenho nada a reclamar de Linux, mas estou vendo uma forma de estar comprando uma placa digium pra usar. Caso, Caso... resolva usar placas nacionais (e até onde eu pesqueisei nao suportam BSD, tomara que descubra estar errado :[). Eu recomendaria placas da digivoice, são muito bem feitas e em LINUX, funcionam bem. Isso é verdade as placas digivoice (até o momento) funcionam muito bem, mas infelizmente só em linux... Basta plugar o E1, esperar o sync e correr pro abraço, transparente, rápido e indolor. []'s Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Duvidas sobre pppoed e mdp
Muito se fala de pppoe Server mas não achei informações concretas, temos vários emails no histórico da lista mas nada que me esclarece algumas duvidas, no google não achei muita coisa. Gostaria de saber do pessoal que usa o pppoe Server ou md5 os prós e contras O pppoed nativo do freebsd está rodando legal na versão 6.x e 7.x (pois antes sei que tinha problemas com rotas e outras coisas na versão 7.x) Sim existiam (ou ainda existem) alguns problemas no ppp(8), mas que não afetam tanta gente assim. As correções já foram aceitas (estão no -current) mas só devem aparecer no 7-STABLE depois do release 7.2 para evitar qualquer incompatibilidade com as versões anteriores. Com os patches aplicados tudo funciona 100%. Qual seria o uso da memória por usuário ? Aprox. 3MB (ou um pouco mais) por usuário. O que séria melhor usar os usuários do sistema ou radius+mysql ? Não existe essa opção de usuários no sistema, existe a opção de utilizar o ppp.secret (um arquivo de usuarios e senhas para conexão do ppp) e a opção do radius. Tudo depende da quantidade de usuários que você pretende utilizar, para alguns poucos usuários o ppp.secret pode lhe atender e para algumas dezenas ou mais de usuários o radius deve ser a sua opção (além de permitir o cadastro de usuario+senha+mac-address e outras features por usuário - controle de banda por exemplo). Para pessoal que usa o mpd5 : Onde acho exemplos, pois já virei a net ? Se tiver exemplos pode me enviar ? Já olhou a documentação do software ? Infelizmente não tenho nenhum exemplo. Como via de regra, para poucas conexões você pode ir de ppp(8) e para algumas centenas ou mais de conexões simultaneas, utilize o mpd. Eu já vi algumas pessoas com quase mil (isso mesmo 1000) conexões pppoe simultaneas com o mpd. Isso é praticamente impossível com o ppp(8) devido ao alto uso de memória por usuário. O mpd também é uma implementação ppp no kernel (netgraph) enquanto o ppp(8) é implementado no userland (que faz alguma diferença se você for ter muitos acessos simultaneos). Será que pppoe é a melhor opção para um isp wireless ? Teria outra boa opção ? Captive portal, 802.1x, certificados, etc... Tudo depende do seu ambiente, SO dos clientes e mesmo da sua estrutura wireless. []'s Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [OFF-TOPIC] Processar e-mail e arquivo anexo
Mauricio Bonani wrote: Anderson Michel escreveu: Pessoal, Surgiu uma necessidade aqui de processar e-mails com arquivo XML em anexo, ref. a NFe. Assim que chegar algum e-mail numa determinada conta, preciso pegar o anexo e gravar numa área para o ERP, e ainda fazer uma resposta ao e-mail, como um protocolo de recebimento. http://wiki.bestpractical.com/view/RTmailgate É específico do RT, mas deve te ajudar a criar um semelhante. Mauricio, Obrigado pela dica, vou ver como funciona esse cara. Anderson Michel Outra opção é utilizar o reformime (instalado junto com o maildrop: /usr/ports/mail/maildrop): mail.xx.com.br# cd /vpopmail/domains/xx.com.br//Maildir/.Arquivo/cur/ mail.xx.com.br# reformime -i 1146075701.M373968P36235V005FI011CFC04_0.mail.xx.com.br,S=41781:2,RS section: 1 content-type: multipart/mixed content-transfer-encoding: 8bit charset: iso-8859-1 starting-pos: 0 starting-pos-body: 1078 ending-pos: 41781 line-count: 612 body-line-count: 587 section: 1.1 content-type: multipart/alternative content-transfer-encoding: 8bit charset: iso-8859-1 starting-pos: 1168 starting-pos-body: 1260 ending-pos: 4864 line-count: 97 body-line-count: 94 section: 1.1.1 content-type: text/plain content-transfer-encoding: 8bit charset: iso-8859-1 starting-pos: 1305 starting-pos-body: 1386 ending-pos: 1873 line-count: 23 body-line-count: 19 section: 1.1.2 content-type: text/html content-transfer-encoding: quoted-printable charset: iso-8859-1 starting-pos: 1918 starting-pos-body: 2010 ending-pos: 4817 line-count: 65 body-line-count: 61 section: 1.2 content-type: application/msword content-name: lista de bens II.doc content-transfer-encoding: base64 charset: iso-8859-1 content-disposition: attachment content-disposition-filename: lista de bens II.doc starting-pos: 4909 starting-pos-body: 5073 ending-pos: 41734 line-count: 483 body-line-count: 477 A opção -e extrai para o stdout a parte especificada do e-mail, por exempo para ler a parte text/plain desse e-mail (segue apenas o comando, sem saída): mail.xx.com.br# reformime -e -s 1.1.1 1146075701.M373968P36235V005FI011CFC04_0.mail.xx.com.br,S=41781:2,RS Luiz - 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: RES: Migrar poptop para FreeBSD 7.1
Estou utilizando a configuração proposta em http://www.freebsdconsult.com.br/artigos/mypage_30_VPN-com-poptop.html Alguem pode me dar uma ajuda? Ola, Aqui faço um pouco diferente: # cat /usr/local/etc/pptpd.conf ppp /usr/sbin/ppp debug logwtmp connections 5 localip 10.0.0.1 remoteip 10.0.0.100-104 # cat /etc/ppp/ppp.conf default: set log Phase Chat LCP IPCP CCP tun command ident user-ppp VERSION (built COMPILATIONDATE) pptp: set timeout 0 enable chap81 disable deflate pred1 deny deflate pred1 set ifaddr 10.0.0.1 10.0.0.100-10.0.0.104 255.255.255.255 enable proxy accept dns set dns 10.0.0.1 # set nbns 10.0.0.11 # servidor wins set mtu max 1490 set mru 1490 disable echo set echoperiod 5 disable ipv6cp Os usuários e senhas podem ser por radius ou ficar no /etc/ppp/ppp.secret E pra funcionar no freebsd 7 ou superior tem que aplicar um patch que corrige as rotas mantidas pelo ppp (http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/130159) e outro que corrige um problema com o proxy arp (http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/131250). Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] FreeBSD para 64 bits
Creio que antes de tudo teremos que levar em consideração que SMP demostra desempenho para aplicações multitreads, no caso teremos que usar uma versão em especifica para obter o ganho de performace que o SMP poderá oferecer. Dizer que um processador com isso ou com aqui é lento é uma coisa, agora tem que ver emque ambiente de fato aquela tecnologia vai dizer que é lenta ou não. Sujestões são bem vindas. Pessoal, Comparar processadores com um sistema operacional multitarefa é o mesmo que contas as gotas no oceano ou os grãos de areia no deserto. Você não tem controle sobre os outros processos/threads/interrupções que param e pedem atenção do processador várias vezes por segundo. É praticamente impossível repetir dois resultados num sistema como esse. Seu processo é apenas mais um. Os HT, (até onde eu sei) se trata de duas cpus físicas, reais mas que compartilham um único cache. Isso nos sistemas multitarefa acaba mais prejudicando do que ajudando, por que ? Simples, com um único cache e os vários programas rodando a cpu precisa se dedicar a todos eles, toda vez que uma das cpu esta executando um processo (provavelmente um diferente do que esta/estava rodando na outra cpu) ela vai invalidar todos os dados na cache (que a outra cpu estava usando para ler/processar outro programa). Em algumas situações (acho que na pratica muito poucas) o HT pode funcionar, desde que os dados na cache sejam uteis para as duas cpus e uma não fique invalidando o cache para a outra. Essa thread já passou do razoavel (para essa lista), acho que podemos parar por aqui. Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] FreeBSD para 64 bits
E onde o assunto discutido está fora do escopo da lista? ou o seu FreeBSD roda sobre estruturas celulares com base em carbono ? Meu(s) FreeBSD(s) rodam em qualquer coisa, qualquer lugar e é por isso que eu simplesmente não ligo. Daquele lixo de computador que ninguem mais usa até o ultimo lançamento ou ainda nas minhas avrs (pra quem não tem dinheiro para comprar um ARM decente). Eu não lligo pra velocidade (desde que tenha velocidade suficiente para fazer o que EU preciso), ligo para segurança, estabilidade, documentação, ambiente de desenvolvimento. Qualquer computador atual tem velocidade de sobra para as minhas necessidades, qualquer coisa além disso é lucro. O assunto esta fora do escopo da lista porque tanto quanto eu o freebsd não liga se o seu processador faz mais do que do outro. Sem flames por favor. Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] FreeBSD para 64 bits
Meu Querido quem gerou flamers de momento não foi eu, se igual a você quase todos os membros das lista já teve a oportunidade de usar algum Risc e quem não teve terá possivelmente. agora saber de fato o que se faz e como se faz é o principio para manter um ambiente controlado e poder alcançar 99% de segurança e se não me engano erros de projeto de hardware também causa vunerabilidades de segurança, ou será que li errado sobre o Atom da intel semana passada ? No flames é simplesmente para você não levar para o lado pessoal... Não existe tecnologia 100% livre de riscos, toda nova solução traz novos problemas, é o desenvolvimento no seu apice. Para as suas necessidades até que pode ser que qualquer computador tem processamento de sobra porém para a necessidades de muitos aqui na lista não, para o que faço 500 mhz com 128Mbs de ram é mais do que o suficiente, porém não é sempre que se faz a mesma coisa e torno a repetir o seu FreeBSD não roda em qualquer coisa. pois para começar não me lembro de ter visto uma estrutura celular com base em carbono rodar o FreeBSD, se o seu faz então disponibilize pois será uma revolução no ambito computacional, e outra o FreeBSD não suporta todas as arquiteturas de processador existentes , se fosse o NetBSD eu fico quieto mais não vem se vangloriando em causas infundadas. Com certeza, se o todo o desenvolvimento da informatica no mundo fosse proveniente das minhas necessidades, estariamos na idade da pedra... Felizmente para cada necessidade há sempre alguem disposto a fazer a diferença. Causa infundada ? Você por acaso tem um desse tal de estrutura celular com base em carbono ai ? Cria uma conta shell pra mim ! :) Desculpe, mas da mesma forma que os meus problemas não são os únicos, você não pode dizer que o FreeBSD pra mim não funciona em todos os lugares... Até telemetria de voo eu faço com ele (http://www.rcgroups.com/forums/showthread.php?t=948923highlight=avr). Portanto não queira me dizer o que eu não posso fazer o com FreeBSD. Nunca disse que o FreeBSD roda em qualquer plataforma (conheco bem suas limitações), o que eu disse é que o FreeBSD roda em todos esses processadores que esta sendo discutidos e pouco importa a MARCA. Se o conteúdo da Thread não o agrada, crie filtro, ou melhor seja inteligênte ignore, pois se para você a discussão está fora do escopo, para mim e outros membros da lista não se encontra com breves excessões para mensagens como as suas e as minhas com respostas destinadas as suas mensagens. Com certeza, nem sei porque respondi da primeira vez. Bem deve ser por conta do mal humor depois de trabalhar a noite toda num Linux. Novamente... sem flames... eu já parei por aqui. []'s Luiz - 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 ZFS com grande quantidade de dados
Boa tarde pessoal. Eu estou utilizando um FreeBSD 7.1 com GEOM e ZFS para montar um storage. Este storage, está parcialmente em produção, digo parcialmente, pq estou tendo que retirar tudo dele. Eu não consigo deixar o storage rodando direto. (...) Rafael, Se a situação é essa, eu faria tudo de novo com o FreeBSD 8 ou -current. Eu tenho acompanhado os bugs na listas e parece que o ZFS esta bem mais estavel nessa versão. Os problemas relatados normalmente são problemas relacionados a bugs no hardware e podem ser contornados desabilitando algumas opções no zfs. Eu tenho um pequeno servidor de testes rodando nessa versão, mas tenho pouquissímo uso do storage para poder garantir qualquer coisa, o que posso dizer é que você não terá grandes surpresas na adoção dessa versão (baixe o ultimo snapshot e depois atualize normalmente para pegar as ultimas correções). O release 8.0 também não deve demorar a sair, sai esse ano, só não se sabe quando... []'s Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Squid x-forwarded-for
Procure por Tproxy. Já rolou na lista. Abraços, Eduardo. Hmm... O tproxy.no-ip.org esta fora do ar, meu link ebt na faixa foi pro espaço :/ Se alguem tiver como colocar isso em algum lugar eu agradeceria (não estou com vontade de levantar o serviço no meu speedy home). []'s Luiz PS: se alguem precisar dos patchs é só entrar em contato em pvt. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] FreeBSD para 64 bits
Eduardo Schoedler wrote:
Um inteiro passa de 32 para 64 bits! =p rsrsrs
Looog, consome mais memória.
Negativo. Já havia feito esse teste antes e fiz novamente agora. Compile
e rode:
#include stdio.h
int main(void) {
printf(%d\n, sizeof(int));
}
- --
João Paulo Just
Diretor Executivo - Justsoft Informática Ltda.
http://www.justsoft.com.br/
É isso mesmo João Paulo, para o tipo int não muda nada. Isso provavelmente
quebraria muitos programas que não foram pensados para trabalhar dessa
maneira (inteiros de 64bits).
A única coisa que muda é o tamanho dos ponteiros (void *), por isso a
maioria dos programas funciona de forma transparente e sem dor de cabeça nos
ambientes 64 bits (já era hora).
Isso aumenta um pouco o uso da memória se você tem o uso de muitos ponteiros
no programa, mas com certeza nada que se compare aos ganhos que você vai
obter.
[]'s
Luiz
-
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: /var crescendo [RESOLVIDO]
Em Wed, 11 Mar 2009 15:19:04 -0300 Renato Botelho rbga...@gmail.com, conhecido consumidor de drogas (BigMac's com Coke) escreveu: Deve ter sido por essa razão que eu coloquei um httpd graceful no cron todos os dias as 0:05h válido e inteligente, porém (sempre um porém): estamos quebrando o galho do aplicativo. Será que não há um modo dele mesmo fazer o limpa disco? Quem rotaciona os logs eh o newsyslog, porém quem os gera é o próprio apache e não o syslog, então o apache fica com o ponteiro preso. O ideal seria se tivesse um jeito de fazer o apache gravar o log via syslog, OU, fazer como o squid, fazer o próprio apache rotacionar os mesmos. -- Renato Botelho Renato, Irado e João, Basta adicionar essas linhas (ou coisa parecida) no /etc/newsyslog.conf: /var/log/httpd/chamados.xxx.org.br-access.log 600 7 *@T00 JC /var/run/httpd.pid /var/log/httpd/chamados.xxx.org.br-error.log 600 7 *@T00 JC /var/run/httpd.pid /var/log/httpd/qmailadmin.xxx.org.br-access.log 600 7 * @T00 JC/var/run/httpd.pid /var/log/httpd/qmailadmin.xxx.org.br-error.log600 7 * @T00 JC/var/run/httpd.pid Isso faz com que o newsyslog(8) mande um SIGHUP para o apache (rodando no pid que esta no arquivo /var/run/httpd.pid) e assim o apache fecha os logs e abre novamente, fechando o processo de rotação de logs. []'s Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] /var/spool/clientmqueue - ERA : /var crescendo
Alguém sabe informar o que exatamente aquele clientmqueue grava? se não me engano é algo referente ao sendmail... Todas as vezes que tive /var cheio foi por causa disso. Eu acho que outro erro é o auto-particionamento, que sempre sugere POUCO espaço para o /VAR... eu geralmente coloco logo uns 10 GB =) -- Welkson Renny de Medeiros Focus Automação Comercial Desenvolvimento / Gerência de Redes welk...@focusautomacao.com.br Welkson, O /var/spool/clientmqueue é uma fila do sendmail para os e-mails enviados pela maquina. Todos os e-mails enviados pelo sistema (periodic(8)) ou qualquer outra aplicação que utilize o sendmail como forma de enviar um mensagem pelo seu servidor vai gerar um arquivo temporário nesse diretório. Quando o sendmail esta desabilidato (o que não é muito incomum) os arquivos vão acumulando lá... Toda maquina deveria ter um smtp (bem) configurado para enviar os e-mails locais. Eu faço isso desabilitando o sendmail (padrão) e instalando um qmail básico (padrão do ports, sem patches, não precisa configurar os serviços de smtp, pop ou imap, só o qmail-queue). Rápido e indolor (ok, nem todos concordam :] ). []'s Luiz - 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: /var crescendo
Aí galera, Tenho um problema identico ao descrito pelo João, a ocupação do /var vai subindo mas quando se rola um df na partição ela está informa a quantidade correta de ocupação da partição, ou seja, alguma coisa louca com o sistema de arquivos. Eu acho que o problema pode estar no syslog, uma vez que é ele que coleta esses dados. Deixa eu entender, quando você diz que vai crescendo mas que o df mostra correto, onde você vê que tá crescendo? No email diário? Se for nesse email, quem coleta os dados é o script /etc/periodic/daily/400.status-disks que por dentro usa o df. Renato, Me parece que o df(1) mostra o espaço utilizado, mas o du(1) não. Isso pode acontecer se em um programa você abre um arquivo (que pode ser criado no momento da abertura) e em seguida faz um unlink(2) nele. O arquivo some (para o du(1), ls(1), etc) mas como existe uma referencia pra ele (file descriptor - fd) o arquivo continua lá e pode ser usado pelo programa que o abriu/criou. O espaço utilizado por esse arquivo só será liberado quando todas as referencias a ele forem fechadas. Eu já vi esse tipo de uso em alguns programas, mas realmente não me lembro onde foi. De qualquer maneira isso é no maximo um educated guess (o famoso chute) :) []'s Luiz PS: o arquivo continua visivel para o fstat(1) - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Quagga Freebsd e multiplas rotas para um mesmo destino
E como que vc trata as rotas para o mesmo destino. Ex o neighbor êh o 192.168.100.1 mas ele está acessível atraves do 10.1.1.1 e 10.2.2.1 e 10.3.3.1 . Resenha um pouco para mim como ficou a sua estrutura. Abraços Matheus, A questão das rotas é simples: # route add default 10.1.1.1 # setfib 1 route add default 10.2.2.1 # setfib 2 route add default 10.3.3.1 Dai basta você marcar os pacotes _na entrada_ para cada tabela fib. Como você não precisa manter as sessões (os pacotes de uma conexão _podem_ ser enviados por links diferentes - você tem apenas vários meios físicos para falar com o mesmo peer) você pode fazer isso com regras prob. # ipfw add prob 0.33 setfib 1 ip from any to any in via $iif # ipfw add prob 0.33 setfib 2 ip from any to any in via $iif Assim você vai direcionar 33% dos pacotes para o gateway 2, 33% para o gateway 3 e o restante (aprox. 34%) para o gateway 1. Não conheco o suporte do pf para as tabelas fib e tão pouco a interação com os daemons de bgp. Abraços, Luiz - 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: SQUID 2.7 Transparent + PF + HT TPS não funciona
Proxy transparente não funciona para HTTP, só HTTPS. Realmente da forma padrão não há como fazer isso. Mas existe uma maneira de se fazer isso, já foi discutido aqui na lista (com o core dumped). É preciso gerar os certificados on-the-fly, bem como ter um CA própria e autorizada nos browsers dos clientes. Um dia eu vou implementar algo assim... (já existem soluções comerciais para isso) []'s Luiz - 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: RES: SQUID 2.7 Transparent + PF + HTTPS não funciona
Sim, mas os clientes terao um susto quando receberem um certificado da CA interna, não do site! Eles teriam que consentir com o man in the middle, hehehe. É preciso gerar os certificados on-the-fly, bem como ter um CA própria e autorizada nos browsers dos clientes. Como eu falei, se a CA estiver autorizada no browser dos clientes, não haverá susto algum. Não deixa de ser um man in the middle consentido pelo adminitrador que instalou o certificado da CA como uma certificadora raiz em cada micro da empresa/rede. Para o usuário final seria completamente transparente. []'s Luiz - 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: squid 3.0 + https + ipfw passando pelos filtros
Se os clientes dele não se importarem do aviso de diferença de certificado, pode ser usado. Mas creio que se for qualquer coisa diferente de uma corporação, ex, ISP, internet condominial, etc, não é viável. Miguel Martins escreveu: squid.conf transparent, não funciona para 443 (https). Funciona sim, favor ler o SSLBUMP [1]. [1]. http://wiki.squid-cache.org/Features/SslBump Renato, Na empresa, na rede que você tem controle (o que não acontece nos provedores...) com a instalação do certificado da CA ou AC (autoridade certificadora) no micro não haverá qualquer aviso sobre qualquer diferença. simples assim. Quando você instala um certificado de uma CA você passa a confiar em todos certificados que ela assina, é o caso da verisign, certsign, etc. Assim quando você instala o certificado do seu proxy nas estações todos os certificados gerados lá serão aceitos como válidos (para qualquer domínio). Você pode deixar uma entidade certificadora e passar a utilizar os serviços de outra, quanto a isso não há segurança :) Por isso essa questão da segurança de certificados é um pouco questionada, é sempre uma reação em cadeia (caso haja algum vazamento de informação). O sslbump faz exatamente isso, eu não conhecia, obrigado Marcio. Luiz - 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: squid 3.0 + https + ipfw passando pelos filtros
Renato Frederick escreveu: Se os clientes dele não se importarem do aviso de diferença de certificado, pode ser usado. Mas creio que se for qualquer coisa diferente de uma corporação, ex, ISP, internet condominial, etc, não é viável. Exato Renato, Isso é muito importante, deixar claro que o certificado não será o do BB, por exemplo, e sim o que ele tem no servidor, o que na minha opinião é uma pessíma idéia de se utilizar. Marcio, Veja que o proxy faz a verificação correta do certificado do banco (se o certificado do banco é válido) e protege você pelo menos desse problema. []'s Luiz - 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: squid 3.0 + https + ipfw passando pelos filtros
Luiz Otavio O Souza escreveu: Marcio, Veja que o proxy faz a verificação correta do certificado do banco (se o certificado do banco é válido) e protege você pelo menos desse problema. Note que quem fará a comunicação com o BB, por exemplo, será o proxy já você, no caso o seu navegador, fará a comunicação com o proxy, lendo o certificado dele, por isso a informação na wiki do squid, sobre o ataque de man-in-the-maddle (squid-in-the-maddle) Sim, uma vez que sua chave vaze (seu servidor esteja comprometido) você não pode confiar em site algum... []'s Luiz - 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: Análise de tráfego na rede
Iftop welkson trafshow (eu particularmente prefiro o /usr/ports/net/trafshow3) Thiago Pessoal, Eu tenho isso (http://www.fug.com.br/historico/html/freebsd/2007-01/msg00224.html) em algum lugar por aqui... Eu gostaria de reviver o dummynetd, quem sabe fazer até um port dele... Ele era muito prático, gerando os gráficos rrd por IP com a possibilidade de se controlar e visualizar a banda em tempo real. Eu cheguei a desenvolver um interface web (toska) pra ele e tenho um amigo que usa isso no provedor dele com cerca de 1000 clientes por maquina (ele adora a possibilidade de consultar o consumo dos clientes em tempo real e eventualmente fazer algum ajuste na banda). Como isso foi no tempo do FreeBSD 6.x ele não funciona nas versões atuais (diferenças nos comandos do ipfw), mas se alguem se interessar em dar um help nesse projeto é só entrar em contato. (enquanto eu procuro onde é que foram parar os fontes daquela versão) Bem, esta feito: http://sourceforge.net/projects/dummynetd Vou separar o sistema aqui, testar e em breve estará disponível. Bom fim de semana a todos e vamos descansar um pouco, vamos voar ! (e tentar ficar longe da manobra da sacolinha... - pra recolher os pedaços - http://www.youtube.com/watch?v=763jf__Zg7g) []'s Luiz PS: Alguem sabe aonde posso conseguir alguns adesivos do beastie ? Camisetas ? A minha do BSD Day já esta branca de tanto lavar :] - 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: Análise de tráfego na rede
Iftop welkson trafshow (eu particularmente prefiro o /usr/ports/net/trafshow3) Thiago Pessoal, Eu tenho isso (http://www.fug.com.br/historico/html/freebsd/2007-01/msg00224.html) em algum lugar por aqui... Eu gostaria de reviver o dummynetd, quem sabe fazer até um port dele... Ele era muito prático, gerando os gráficos rrd por IP com a possibilidade de se controlar e visualizar a banda em tempo real. Eu cheguei a desenvolver um interface web (toska) pra ele e tenho um amigo que usa isso no provedor dele com cerca de 1000 clientes por maquina (ele adora a possibilidade de consultar o consumo dos clientes em tempo real e eventualmente fazer algum ajuste na banda). Como isso foi no tempo do FreeBSD 6.x ele não funciona nas versões atuais (diferenças nos comandos do ipfw), mas se alguem se interessar em dar um help nesse projeto é só entrar em contato. (enquanto eu procuro onde é que foram parar os fontes daquela versão) []'s Luiz - 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: Powered PPPoE
Marcio e Renato Obrigado pelas resposta. Assumi essa empresa como administrador de redes a uma semana e olha como o antigo administrador fazia as coisas a rede é uma grande rede mesmo em que os usuários não tem nenhum tipo de autenticação, por exemplo todos estão em IPs válidos separados em classes Cs cada classe suporte 254 clientes então ia crescendo assim todos clientes com mascara 255.255.255.0 um gateway so de saida. A rede tem muito broadcast , netbios , virus , clientes trocando IPs e dando conflito de ips na rede a todo momento a rede cai, a coisa esta feia aqui, por isso queria a opinião de vocês em relação ao PPPoE que vejo ser a uma das unicas soluções para mim organizar essa farra. Obrigado, Luís Luís, Fora os detalhes de implementação que o pessoal já comentou, a parte tecnica funciona muito bem. Você tem suporte a todo tipo de autenticação (LDAP, SQL, etc, etc) via radius, controle de banda, controle por mac address, controle por volume, IP fixo, IP dinâmico, enfim tudo que você pode precisar para controlar as conexões do seu provedor. Outra vantagem é o aproveitamento dos IPs, já que você não precisa criar classes para fazer o p-t-p, cada cliente vai utilizar apenas um IP. Eu tive contato com algumas pessoas que utilizam com muito sucesso concentradores PPPoE em FreeBSD com mais de 2000 usuários simultâneos (um tanto alto para tudo que eu já tinha visto em termos de PPPoE). Eu fiquei de montar um concentrador desses (com o setup indicado) para fazer alguns testes, mas... pra variar ENOTIME again... []'s Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Servidores rack
Bom dia amigos, Renato esse Dell PowerEdge 1950 funciona tudo out off box, ou seja, direto da embalagem pra o FreeBSD 7 sem gambi? Cleber Cleber, Veja a saída do dmesg em um Dell 2850 rodando FreeBSD-Current para testes do zfs (instalado sem qualquer gambi - it just works !): Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #0: Mon Feb 2 15:17:20 BRST 2009 r...@mail2..com.br:/usr/src/sys/amd64/compile/mail Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2793.02-MHz K8-class CPU) Origin = GenuineIntel Id = 0xf48 Stepping = 8 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x649dSSE3,DTES64,MON,DS_CPL,EST,CNXT-ID,CX16,xTPR AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF TSC: P-state invariant Cores per package: 2 Logical CPUs per core: 2 usable memory = 4280885248 (4082 MB) avail memory = 4125200384 (3934 MB) ACPI APIC Table: DELL PE BKC FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0: Changing APIC ID to 8 ioapic1: Changing APIC ID to 9 ioapic2: Changing APIC ID to 10 ioapic3: Changing APIC ID to 11 ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 32-55 on motherboard ioapic2 Version 2.0 irqs 64-87 on motherboard ioapic3 Version 2.0 irqs 96-119 on motherboard kbd1 at kbdmux0 acpi0: DELL PE BKC on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 900 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge at device 2.0 on pci0 pci1: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 0.0 on pci1 pci2: ACPI PCI bus on pcib2 amr0: LSILogic MegaRAID 1.53 mem 0xf80f-0xf80f,0xfe9c-0xfe9f irq 46 at device 14.0 on pci2 amr0: Using 64-bit DMA amr0: [ITHREAD] amr0: delete logical drives supported by controller amr0: LSILogic PERC 4e/Di Firmware 521X, BIOS H430, 256MB RAM pcib3: ACPI PCI-PCI bridge at device 0.2 on pci1 pci3: ACPI PCI bus on pcib3 pcib4: ACPI PCI-PCI bridge at device 4.0 on pci0 pci4: ACPI PCI bus on pcib4 pcib5: ACPI PCI-PCI bridge at device 5.0 on pci0 pci5: ACPI PCI bus on pcib5 pcib6: ACPI PCI-PCI bridge at device 0.0 on pci5 pci6: ACPI PCI bus on pcib6 em0: Intel(R) PRO/1000 Network Connection 6.9.6 port 0xecc0-0xecff mem 0xfe6e-0xfe6f irq 64 at device 7.0 on pci6 em0: [FILTER] em0: Ethernet address: 00:13:72:5f:a1:b3 pcib7: ACPI PCI-PCI bridge at device 0.2 on pci5 pci7: ACPI PCI bus on pcib7 em1: Intel(R) PRO/1000 Network Connection 6.9.6 port 0xdcc0-0xdcff mem 0xfe4e-0xfe4f irq 65 at device 8.0 on pci7 em1: [FILTER] em1: Ethernet address: 00:13:72:5f:a1:b4 pcib8: ACPI PCI-PCI bridge at device 6.0 on pci0 pci8: ACPI PCI bus on pcib8 pcib9: ACPI PCI-PCI bridge at device 0.0 on pci8 pci9: ACPI PCI bus on pcib9 pcib10: ACPI PCI-PCI bridge at device 0.2 on pci8 pci10: ACPI PCI bus on pcib10 ahd0: Adaptec 39320 Ultra320 SCSI adapter port 0xcc00-0xccff,0xc800-0xc8ff mem 0xfe1fe000-0xfe1f irq 101 at device 3.0 on pci10 ahd0: [ITHREAD] aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 101-133Mhz, 512 SCBs ahd1: Adaptec 39320 Ultra320 SCSI adapter port 0xc400-0xc4ff,0xc000-0xc0ff mem 0xfe1fc000-0xfe1fdfff irq 102 at device 3.1 on pci10 ahd1: [ITHREAD] aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 101-133Mhz, 512 SCBs uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0x9ce0-0x9cff irq 16 at device 29.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x0f10 usbus0: Intel 82801EB (ICH5) USB controller USB-A on uhci0 uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0x9cc0-0x9cdf irq 19 at device 29.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x0f10 usbus1: Intel 82801EB (ICH5) USB controller USB-B on uhci1 uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0x9ca0-0x9cbf irq 18 at device 29.2 on pci0 uhci2: [ITHREAD] uhci2: LegSup = 0x0f10 usbus2: Intel 82801EB (ICH5) USB controller USB-C on uhci2 ehci0: Intel 82801EB/R (ICH5) USB 2.0 controller mem 0xfeb0-0xfeb003ff irq 23 at device 29.7 on pci0 ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: Intel 82801EB/R (ICH5) USB 2.0 controller on ehci0 pcib11: ACPI PCI-PCI bridge at device 30.0 on pci0 pci11: ACPI PCI bus on pcib11 vgapci0: VGA-compatible display port
Re: [FUG-BR] RES: Placa rocketRaid - RESOLVIDO
Pronto, depois de quebrar a cabeça, é o seguinte: Se o sistema estiver instalado e você carregar a placa no prompt com um 'kldload rr26xx' ele não detecta. Tem que copiar pro /boot/kernel e colocar no loader.conf. só assim ele detecta. Porque só antes do sistema carregar ele funciona, não sei falar, eu costumo carregar drivers de rede ou wireless desta maneira(para evitar que um driver defeituoso trave o sistema) e nunca tive problemas. Agora irei instalar os utilitários WEB e ver se funciona :) Renato, Existem configurações e modulos que precisam ser carregados antes do boot do kernel (pre-load). É o caso do/da acpi e de certos parametros que só podem ser alterados via loader.conf (maxusers, etc etc etc). São modulos que precisam estar presentes tão logo o kernel comece a rodar para tomar certas decisões sobre o funcionamento do sistema (e algumas não podem ser alteradas enquanto o sistema esta em funcionamento). Já os detalhes só são conhecidos pelos autores do driver e como me parece que se trata de um driver fechado, ficaremos sem maiores esclarecimentos... []'s Luiz - 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: RES: RES: RES: Placa rocketRaid
é sata o cabo de força tem o pino laranja em conjunto com o amarelo preto e vermelho tem propriedades de hot swap verifique se a sua controladora tem suporte a hot swap se tiver ative e efetue testes. removendo o cabo sata do hd William, Provavelmente essa conexão só estará disponível se ele tem uma fonte com saída para sata, no caso de adaptadores, não há nada mais que terra, +5V e +12V (a partir dos conectores para HD/CD). O laranja normalmente é utilizado para +3.3V, mas poderia ser algum tipo de power good para os hds (realmente não sei). O segredo do hot swap esta nos conectores, existem conexões que são feitas mais longas do que as outras, assim na conexão do cabo essas conexões mais longas são as primeiras a funcionar e normalmente transmitem a energia para o sistema (assim ele pode ligar e inicializar a sua cpu antes das conexões lógicas serem efetuadas). De qualquer maneira é preciso haver um suporte da parte lógica para lidar com essa situação (dispositivo pode ser adicionado/removido a quente). O mesmo acontece com o USB (pode reparar que existe duas conexões mais longas e duas mais curtas), o dispositivo primeiro recebe a energia e só depois a parte lógica é conectada. []'s Luiz - 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: RES: Placa rocketRaid
Adaptors exist which can convert a 4-pin Molex connector to a SATA power connector. However, because the 4-pin Molex connectors do not provide 3.3 V power, these adapters provide only 5 V and 12 V power and leave the 3.3 V lines unconnected. This precludes the use of such adapters with drives that require 3.3 V power. Understanding this, drive manufacturers have largely left the 3.3 V power lines unused. However, without 3.3 V power, the SATA device may not be able to implement hotplugging as mentioned in the previous paragraph. é pra isso que seve o 3.3V. ( Hot Plug ) Dificilmente a falta de 3.3V vai fazer um drive não ser hotpluggable. Essa tensão (3.3V) normalmente é utilizado para alimentar a CPU (também nas linhas de i/o - os dados da usb por exemplo funcionam em 3.3V embora o usb forneça 5V para alimentação ;)), mas como hoje em dias as cpus consomem muita pouca energia seria bem simples utilizar um regulador LDO (low dropout) para se obter os 3.3V a partir dos 5V como se faz na usb. Veja que a nota diz que os próprios fabricantes tem evitado a necessidade dos 3.3V. outra coisa você acaba de mencionar que usa um servidor DELL qual modelo ? Se ele tem uma gaveta que vc encaixa os hd e pluga ela no servidor isso pelo que conheço é um back plane . e isso é HOT SWAP. Ele deve ter um daqueles modelos torre mais simples, sem qualquer tipo de backplane. HDs internos. []'s Luiz - 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: Placa rocketRaid
O disco é SAS, mas o cabo é normal.. é sata o cabo de força tem o pino laranja em conjunto com o amarelo preto e vermelho tem propriedades de hot swap verifique se a sua controladora tem suporte a hot swap se tiver ative e efetue testes. removendo o cabo sata do hd Eu desligaria apenas a energia do disco, como no caso do SAS cada disco tem seu próprio canal de i/o, mesmo o disco permanecendo conectado no canal não trará problemas aos outros discos (diferente do IDE, onde um disco sem energia plugado no mesmo barramento que outro, pode prejudicar e até evitar o funcionamento do disco online). Provavelmente seu disco SAS é hotswap, a duvida talvez seja a controladora ou mesmo as conexões (seu gabinete não tem um back plate para hotswap). Se você quiser evitar problemas, desligue seu servidor, remova um disco e ligue novamente o servidor (não é o melhor teste, mas lhe dará uma boa idéia do que pode acontecer quando seu disco resolver tirar férias). Eu já vi (um) caso de um diretor chegar com uma visita para mostrar os servidores da empresa e para demonstrar a capacidade contra falha do sistema, removeu um disco do raid do servidor em pleno horario comercial... 2000 pontos de call center ficaram parados por quase uma hora... e pra sorte de todos os envolvidos nesse episódio o servidor apenas travou não houve perda dos dados no raid (mas o SO teve que fazer sua verificação de rotina depois da travada do servidor - o que levou um bo tempo). Embora funcionem muito bem todos esses hardwares de raid (eu gosto de testar durante a instalação do SO), não arrisco muitos testes em produção (em time que esta ganhando...). Também é normal hds de alta performance apresentarem problemas no 3 primeiros meses, portanto fique atento. Aqui de 4 servidores HP instalados numa certa ocasião, dois precisaram ter um dos seus HDs substituitos. A parte boa é que você chega, o HD esta vermelho, você olha pela janela e esta todo mundo trabalhando. []'s Luiz PS: Outro dia um desses servidores HP estava indicando um falha interna. Fui verificar, dentro havia outro led indicando que se tratava de memória e havia ainda outro led que me dizia em qual banco estava o problema (um led por banco de memória) e novamente todo mundo trabalhando feliz. Nessas horas eu fico muito feliz que meus clientes entendam a necessidade de se investir em bons hardwares. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [Off-Topic] diferenças entre FreeNA S e FreeBSD
É a mesma questao que debato e ateh hj nao tive resposta: No mesmo hardware (tanto pc ou routerboard) com a mesma placa pci wireless, o que eh melhor: FreeBSD tunado na unha, ou o mikrotik??? E nao vale dizer q o mikrotik eh melhor pq tem a interface winbox pra administrar. Mario, Na época que foi lançado o driver ath no FreeBSD (na época do 5.x migrando para o 6.x) eu tentei montar um backbone na cidade para um amigo (dono de um ISP). Eu trabalhei muito e fiz todos os testes e alterações ao meu alcance (testei versões novas do ath_hal, alterei o slot time, alterei a forma como o driver trabalhava - interrupções, voltei o driver para o giant lock - isso resolveu vários panics na época), mas nunca (na época) conseguimos grandes taxas a mais de 1.5Km (~1 milha). Em testes de laboratório (bancada) o driver era capaz de atingir 100% da banda. Na mesma época o mikrotik já fornecia um driver completamente funcional para as atheros, ou seja, eles tem um desenvolvimento a parte, fechado e mantem seus próprios drivers e várias funcionalidades diferentes. Eu não estou defendendo o mikrotik (não uso, nunca usei, mas já procurei me informar), mas acho que tem espaço pra todo tipo de solução (abertas e pagas/comerciais). O problema é que ninguem quer pagar nada por software livre, a empresa troca tudo por mikrotik, mas não investe um real no desenvolvimento/correção do open-source. Gente software aberto, open-source ou seja lá o que for NÃO é de graça, existe um custo (muilto alto por sinal) para se manter o software disponivel para todos nós, então sempre que possível mudem essa idéia dos usuários finais/clientes para que possamos promover e melhorar todos os softwares que fazem nossa vida mais fácil, sem falar no valor dos profissionais que atuam com softwares livres :) []'s Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] Bugathon - Network related PRs
Srs., Acredito que alguns de vocês acompanham e outros talvez não, então lá vai a chamada para todos... Nesse final de semana será feito um bugathon para os problemas relacionados a rede no FreeBSD. Nos bugathon é reunido o máximo possível de pessoas interessadas e a partir dai vários PRs serão revistos na tentativa de fechar o maior número PRs possível. Se você tem um PR aberto ou um problema que esta lhe atrapalhando ai a bastante tempo, talvez essa seja a hora de conseguir uma correção. Também é possível contribuir com testes e em outras atividades que não programação. Quem tiver disponibilidade, de uma passada no #freebsd-bugbusters na efenet nesse fim de semana (começando hoje). []'s Luiz PS: http://wiki.freebsd.org/Bugathons/January2009 - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Resolv.conf alterado no boot DHCP habilitado
Pessoal na ADSL coloco para o pppoe discar, no resolv.conf coloco a interface pra pegar dhcp, quando reinicia ele muda o meu resolv.conf.save, save como mudar isso ? Juliano, disable dns deny dns Isso resolve :) []s' Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Dois servidores com Squid.
Boa noite, amigos. Mais uma vez venho pedir auxilio a vocês, e primeiramente gostaria de agradecer pelas respostas que nos tem me dado. Obrigado! Tenho outra dúvida, pra variar! Na empresa tem um servidor (192.168.0.1) que compartilha a internet para todos e tem o squid instalado, na qual os usuários utilizam essa navegação 'passando' por este squid. E eu agora estou montando um novo servidor, na verdade é só para brincar e aprender a mexer no FreeBSD, e gostaria de instalar o squid, mas não sei como fazer com que alguns usuários (ou apenas eu para testar) 'passar' pelo squid desse outro servidor (ip: 192.168.0.224). Preciso adicionar alguma regra no meu firewall do server principal para liberar esse server novo? Preciso trocar a porta do squid e fazer com que eu passe pelo squid do server novo? Como eu faço? Aguardo auxílio. Obrigado, Carlos! O proxy é transparente ou via socks ? Se for transparente, basta criar uma regra fwd que pegue apenas o IP que você quer testar e aponte só ele para o proxy. Já que você vai testar, eu aconselho você a testar o cacheboy, um fork do squid que esta recebendo muit atenção nas correções de bugs. Experiemente, você não vai se arrepender. []'s Luiz - 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: Dúvida boba da configuração do Mysql
Fábio, boa noite! O my.cnf não vem em /var/db/mysql. Na verdade, se você precisar configurar algum parâmetro no Server mysql ou no client, você o cria em /var/db/mysql e adiciona as diretrizes apropriadas nas sessões [mysqld] e [client], reiniciando o Server depois. Só lembrando que a versão estavel do mysql é a 5.1.30 :) # cd /usr/ports/databases/mysql51-server # make install clean Já pra quem vai atualizar das versões antigas, será preciso recompilar todos so programas que dependem (usam) o mysql. []'s Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] Cacheboy esta sendo renomeado
Srs. e Sras., O projeto cacheboy esta mudando seu nome para lusca (um tipo de monstro marinho não totalmente catalogado - o google É seu amigo) e busca através desse novo caminho uma melhor e maior visibilidade como comunidade opensource. O novo site já foi providenciado e esta disponível em: http://www.lusca.org Eu fiz um contato muito interessante com o Adrian Chadd para o desenvolvimento do tproxy no freebsd e tive a oportunidade de conhecer melhor o trabalho dele a frente do cacheboy, agora lusca. Recomendo a todos que utilizam squid que façam um teste com o lusca, como eu fiz e espero que vocês tenham a mesma impressão que eu: HMMM ele é rápido ! Não há qualquer diferença na estrutura, você pode usar o seu squid.conf no lusca, enfim a migração é bemmm tranquila. E claro, haverá um suporte especial para nós brasileiros, e em ultima instancia eu mesmo estou disposto a contribuir com os colegas brasileiros que precisem de alguma ajuda, ou seja, o lusca terá seu lugar ao sol aqui no Brasil. Sem mais e certo da atenção de todos, Muito obrigado, Luiz PS: Todos estão convidados a participar e colaborar (http://www.lusca.org/participate.html) - 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: Cacheboy esta sendo renomeado
Opa.. Irei testar aonde já tenho o squid 3.0 com tproxy, que inclusive o próprio Luiz me deu algumas dicas e pedir um feedback dos admins para verificar se reportam mais velocidade. Também irei acompanhar o histórico de uso de processamento e verificar se há alguma queda :) Nos ports a instalação do 'lusca' continua sendo pelo port cacheboy16[1]? [1]http://cvsweb.freebsd.org/ports/www/cacheboy16 Isso mesmo Renato, a mudança esta acontecendo primeiro na parte institucional e depois deverá ser replicada no restante do sistema e também nos ports, mas isso com certeza levará mais tempo. []'s Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Cacheboy esta sendo renomeado
Olá Luiz,
Aproveito seu e-mail pra falar sobre os pathes do tproxy no freebsd.
Instalei e ele funcionou.
Mas surgiram algumas limitações bastante complicadas.
1 - Ele não faz cache de ip que não esteja com a rede conectada na
placa
local.
2 - Ele não suporta mais de uma interface de rede fazendo saida pra
cliente (temos 4).
3 - Ele não suportou os skipto de sites como a caixa (famigerado
conectividade social)
Não tive tempo de testá-lo melhor. Vi que ele estava repassando o ip,
mas não vazia cache de ips reais de clientes que estão atrás de outros
dispositivos de roteamento (como mikrotik)
Sei que está e versão beta mas essas coisas que citei acima são
extremamente necessárias pra serem usadas em provedores.
Parabéns pelo trabalho
Ademir,
Existe sim uma parte do patch que não foi publicada e que é a responsável
pelo funcionamento de sistemas mais complexos (sistemas com uma só placa de
rede e também no modo bridge). Esse patch não foi publicado porque
atualmente ele não funciona :) Será preciso reescrever essa parte para o
código atual.
Tirando essa parte bem especifica, eu acredito que os problemas que você viu
por ai são possíveis de serem contornados mesmo na situação atual. Você
provavelmente esta usando os meus exemplos de regras que contém alguma
limitações, mas na verdade o ipfw permite algumas variações que acredito que
possam resolver os problemas que você citou.
Para seus testes talvez essas regras deixem as coisas mais claras:
ipfw add fwd 127.0.0.1,3128 tcp from 200.200.200.0/24 to any 80 in via
${iif} # default rule to transparent proxy
ipfw add fwd 127.0.0.1 tcp from any 80 to 200.200.200.0/24 in via ${oif} #
catch the packets that come back using the clients IPs
Não é necessário utilizar o IP da rede de clientes como no meu exemplo do
site. Isso ajuda ? Eu imagino que isso resolva os problema 1 e 2.
O problema 3 também é possível de ser resolvido adicionando essas regras
ANTES das regras de fwd:
ipfw add skipto XXX tcp from 200.200.200.0/24 to ${caixa} 80 in via {$iif}
ipfw add skipto XXX tcp from ${caixa} 80 to 200.200.200.0/24 in via ${oif}
Embora a solução atual seja digna do RF (meu parceiro de gambiarras), ela é
bem funcional, basta você exercitar seu conhecimento de ipfw que é parte
essencial dessa solução.
Qualquer duvida entre em contato.
Abraço,
Luiz
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Cacheboy esta sendo renomeado
Embora a solução atual seja digna do RF (meu parceiro de gambiarras) Apenas deixando claro... RF stands for : Roberto Fagundes O Cara quando se precisa de alguma gambiarra... (só não da muita idéia que vai complicar o processo de criação... uahuauahuh). Antes que alguem culpe o Renato Frederick por qualquer ajuste tecnico... - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] TProxy em FreeBSD
Luiz, mais em relação a despempenho o Tproxy é a mesma coisa do noss proxy convencional ? Att, Renato Maia Renato, Sim e não, veja: Não porque ele consome mais cpu (overhead do protocolo) para fazer o redirecionamento de pacotes (ipfw fwd, 1 syscall a mais por conexão, etc etc) e isso pode ser significativo dependendo do seu hardware. Já para o seu usuário final, se o seu hardware estiver adequado ele não perceberá (a taxa de transferencia do proxy deve ser bem mais alta que a banda do usuário final). Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] qmail moderno / ZFS - era: Re: ZFS e FBSD 7.1
Apenas complementando, não sei quando será feito o merge, mas o Free -CURRENT está com a versão 13. William, Minha saga com o zfs e o -current em produção começa hoje... vou migrar um servidor de e-mail de 2006, esse servidor indexa e mantém todas as mesangens recebidas e enviadas por um período de 2 a 3 anos (depois existe um arquivo morto para tudo desde de 1999...). Paranóias a parte, vou atualizar esse qmail e gostaria da opnião dos colegas sobre os patchs modernos do qmail, tal como o do Rodrigo, que é muito bom por sinal, mas também gostaria de saber das opções existentes no ports. []'s e obrigado, Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] qmail e remote concurrency
Opa Alexandre. Realmente me expressei errado, o qmail-remote é um processo e não uma thread, e o Ext-todo realmente irá separar a entrega e chegada de e- mails no qmail-todo. Troquei as bolas com o Big-concurrency que este sim irá dar suporte ao qmail-spawn e todo de abrir mais do que 500 processos do qmail-remote. Perfeito! Estive olhando seu site, BEM legal esse patch para limite de entrega por domínios, você mesmo que fez ?? O patch que forneci em: http://www.fug.com.br/historico/html/freebsd/2006-05/msg00925.html é de minha autoria, quando pra minha surpresa o Welington apresentou esse link: http://www.fug.com.br/historico/html/freebsd/2006-05/msg00964.html o qual eu desconhecia. Suponho que patchs perdidos assim são de domínio publico, então nada a declarar... []'s Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] libxcb.so.1 not found, required by libcairo.so.2
Bom dia galera, pela primeira vez uma atualização via ports quebrou meu sistema e isso me deixou preocupado. para quem conhece mais a fundo o sistema, não são feitos testes do port na arvore ports antes que estes sejam postos nela? porque cargas d'água uma simples atualização, simplesmente remove a versão da lib, instala a nova, e não cria nem um link simbólico para versão antiga? achei que eram feitos testes também nas atualização dos ports, não só na inclusão de novos ports na árvore. Isso não é possível... você já viu quantos softwares estão no ports ? Já imaginou quantas combinações são possíveis ? Já penseu testar todas elas ? Nem se fala nas atualizações... cada software faz o que quiser o FreeBSD não tem como rastrear todas essas mudanças e saber o que não vai funcionar e aonde. Infelizmente essa é a responsabilidade do usuário, manter a sua casa em ordem. Nem sempre um link de uma versão nova da biblioteca para a versão antiga funciona, depende muito do que mudou de uma versão para outra. Não há regra quando se trata de atualização, depende dos desenvolvedores do software estarem dispostos a fazer a vida do usuário mais fácil. []'s Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [OFF-TOPIC] Rede PCIe X4
Pessoal, Desculpem pelo off-topic. Preciso comprar uma placa de rede PCIe x4 para um servidor Dell. Estou em SP e um amigo já rodou a Sta. Ifigênia e disse que não encontrou. Gostaria de saber se alguém tem alguma dica de onde comprar e quais recomendam com relação a compatibilidade com o FreeBSD. TIA, Vinicius Maia Vinicius, Quando precisei dessas placas, comprei na propria dell. Veio uma intel gigabit show de bola, vale a pena :) Na sta. ifigenia acho dificil encontrar esse tipo de hardware especializado (placas digium/digivoice, wireless que não dlink/linksys/planet/basicos, etc, etc...). De qualquer maneira de uma olhada na DDR informatica, na rua vitória. []'s Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Cacheboy 1-6 com TPROXY
Pessoal, alguns já viram, mas o cacheboy 1-6, que já esta no ports já esta com a opcao de TPROXY-FREEBSD agora so falta testar. Adailton Milhorini Adailton, Por enquanto suporte nativo só no -current. A alteração virá para o 7-STABLE nos próximos dias, mas no 7.1 RELEASE nem pensar... No 7.1 RELEASE e enquanto o 7-STABLE não receber a mudança, o patch do kernel disponível em http://tproxy.no-ip.org resolve. []'s Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] TPROXY - FREEBSD
Pessoal, graças ao Trabalho do Luiz, o tproxy está funcionando com sucesso em meus servidores. Troquei alguns emails com ele e com a ajuda dele subi com sucesso em um Freebsd 7.1. Parabéns ao Luiz e todos os envolvidos nos patches, sou mais um usuário satisfeito hahahaha Grande notícia, esses patches foram ou serão enviados para o projeto? -- Renato Botelho - Renato, O Adrian@ esta acompanhando isso de perto e ontem mesmo já pediu a revisão da parte de código do kernel. No entanto ainda faltam testes importantes para a solução, já que ela pode ser implementada em alguns cenários diferentes. Falta um pedaço de código do ipfw (que não esta funcionando - código antigo provavelmente antes do smpng) e outro pedaço de código para o funcionamento no modo bridge. Estamos tratando isso como patchs diferentes para que fique mais fácil tanto nos testes quanto na revisão/commit do código. Assim que for commitado a primeira parte do código, podemos enviar um pr para adicionar o suporte ao tproxy no port do squid. Oficialmente, me parece que o cache_boy vai sair de fabrica com esse suporte antes que o squid. A versão para testes já esta no svn do Adrian e deverá estar pronta a tempo do cache_boy-1.6. Aqui estao os arquivos do Adrian: http://people.freebsd.org/~adrian/sys/spoof_bind/ (que inclui também os patchs com problema e não testados) []'s Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] TPROXY - FREEBSD
O Squid-3.HEAD já vem com suporte ao TProxy de fábrica. Não sei se ele está no ports. Abraço! Eduardo, Se não me engano o squid vem o que eles chamam de tproxy2, que é bem diferente da versão tproxy do freebsd. Vi um código da versão tproxy4 que é muito parecido com o código do freebsd, acredito que a distância entre as duas deve diminuir com o tempo. Por enquanto você tem duas opções diferentes no configure do squid para ativar o tproxy do linux e do freebsd, parece que o cache_boy vai pelo mesmo caminho. []'s Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Sistemas de arquivos.
Pessoal, Just because ZFS is in 7.0-RELEASE does *not* mean it works with the default GENERIC kernel! In fact, you are highly likely to experience kernel panics under any kind of load with ZFS and a GENERIC kernel. Medo... muito medo... Uia... que mensagem estimulante... Como é experimental, para quem gosta de adrenalina é muito estimulante, exceto em servidores em produção, a velocidade que emociona é a mesma que mata!!! Não é bem assim, vocês estão falando do ZFS da época do FreeBSD 7.0 (que falando sinceramente... já esta ultrapassado.. hehehe) Se você der uma olhada nas listas de discussão em ingles, você verá que tem muita gente usando o ZFS em produção e ao que tudo indica, sem muitas dores de cabeça. Os problemas aconteceram justamente na época que o 7.0 foi lançado, depois disso muita gente começou a usar o ZFS e o retorno desses usuários já gerou resultados (verifique os PRs). Nesse meio tempo também houve uma atualização da versão do ZFS no FreeBSD (também no solaris). No Wiki do ZFS (http://wiki.freebsd.org/ZFS) você encontrará detalhes sobre tunning (recomendado rodar em amd64) e os patchs que você pode precisar para rodar seu ZFS em produção :) De qualquer maneira é recomdado (nessa fase experimental) o uso do ZFS por pessoas que tenham condições de resolver seus proprios problemas (não espere suporte) e faça backups ! []'s Luiz - 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: RES: RES: RES: RES: RES: Sobre segurança
OK. Perdão pelo off. Voltando ao assunto segurança, me identfiquei bastante com as idéias do Paulo Henrique. Em dezembro passado uma empresa deixou um appliance aqui para filtragem e proxy de http, https e ftp. O produto era uma maravilha: fazia tudo que o Squid e o DansGuardian fazem além de fazer filtragem de requisições https (só dois produtos fazem isso no mercado) e de hora em hora atualizar as blacklists. Tudo isso administrado de uma interface Web simples e intuitiva, com integração segura com AD, autenticando os usuários e grupos de usuários via NTLM. Core, O controle de acesso a sites SSL (https) é feito de maneira transparente ? Ou é configurado o proxy socks nos browsers ? []'s Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Sistemas de arquivos.
O que ele quer é um storage, e não espaço compartilhado. O UFS (ou FFS, os dois nomes para a mesma coisa) não suporta versionamento de arquivos. Ou seja, a cada alteração, o FS registra apenas os bits alterados, mantendo todos os anteriores, e entregando sob demanda o grupo de bits em disco referentes à versão solicitada. Esse tipo de solução é requer sempre um hardware de altíssima velocidade, e OS extremamente otimizado, visto que é, por princípio simples, uma solução completamente fragmentada no que tange ao disco físico (o arquivo fica extremamente distribuído nos RAIDS). Sempre que vi isso sendo proposto, eram soluções de storages que valiam, no mínimo 500k (isso há uns 3 anos atrás). Pablo, Você esta confundindo as coisas... Um snapshot (visões do disco/arquivos no tempo) não tem nada a ver com a distribuição física dos discos (nem depende de disco ou RAID necessariamente) uma vez que é implementada no sistema de arquivos. O próprio UFS suporta snapshots (no começo - freebsd5.0 - isso dava muitos problemas, mas acredito que já esteja corrigido e pronto para uso). Veja o manual do mount(8) na parte do snapshot . O ZFS e alguns outros sistemas de arquivos também suportam snapshots (assim como praticamente toda storage que se preze). A questão de dividir fisicamente o arquivo em vários discos, isso é estragéia do sistema de RAID, cada tipo de RAID grava os arquivos de uma maneira (distribuiu os dados fisicamente de formas diferentes), mas isso tem mais a ver com os riscos envolvidos em se perder um HD. Você pode fazer snapshots no seu free sem gastar nada, não se iluda com nomes bonitos (e preço$) das soluções comerciais, quanto mais simples a solução, melhor ela é (e ninguem precisa saber...). []'s Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
