Re: [FUG-BR] 2 links (Velox e Virtua) no freebsd
> Eu nunca vi esse cenário de quagga para balancear 2 conexões adsl > (acho até que não existe). Poderia exemplificar isso? É mais fácil quando os IPs são estáticos, mas dá pra fazer via dhcp. Eu já fiz com BGP, que torna mto mais fácil, mas redes pequenas como as de banda larga caseira, via docsys ou adsl, não tem essas opções. Acho que seria algo como: conf t interface em0 descr "Interface on netvirtual" ip 200.1.2.2 netmask 255.255.255.252 no shut interface em1 descr "interface On veloquix" ip 210.100.200.2 netmask 255.255.255.252 no shut interface em2 descr "Internal interface - my intranet" ip 192.168.0.1 netmask 255.255.255.0 no shut router rip version 2 network 210.100.200.0 network 200.1.2.0 Teria de acertar somente as partes de rede (tira os IPs que coloquei aqui, que foram só pra ilustrar). Se os modems estiver no modo router e enviando os endereços de rede, provavelmente vai chegar um anúncio de default route. Mas se tiver em bridged isso tudo vai por água abaixo. Dae tem acho eu que o iproute2 do Linux tem mais opção para configuração. -- []´s Helio Loureiro http://helio.loureiro.eng.br http://hloureiro.multiply.com http://twitter.com/helioloureiro - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] 2 links (Velox e Virtua) no freebsd
Eu nunca vi esse cenário de quagga para balancear 2 conexões adsl (acho até que não existe). Poderia exemplificar isso? Carp tbm não serve. O cliente quer balanceamento de conexão e não alta disponibilidade de link/hardware. IMHO pfsense ou pf com load balance [1] são as opções mais faceis de serem implementadas. Quanto a poder monitorar se um link está inativo e enviar as requisições ao outro pode usar ifstated + anchors do pf, em algum lugar do histórico tem um exemplo meu. [1] http://cvs.openbsd.org/faq/pf/pools.html#outgoing Em 27 de fevereiro de 2010 15:53, Helio Loureiro escreveu: >> carp não é usado para redundância entre 2 ou mais servidores? >> >> creio que no caso dele é exatamente igual ao tópico que foi discutido >> ontem[1]! >> >> >> Abraços >> >> [1] http://www.fug.com.br/historico/html/freebsd/2010-02/msg00518.html > > No caso, acho que o melhor seria utilizar um protocolo de roteamento, > talvez RIP uma vez que é a única coisa falada por modems ADSL. > > Sugeriria usar o quagga. > -- > []´s > Helio Loureiro > http://helio.loureiro.eng.br > http://hloureiro.multiply.com > http://twitter.com/helioloureiro > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > -- Giancarlo Rubio - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] PPPoa
Da uma olhada amigo. http://www.freebsd.org/doc/en/books/handbook/pppoa.html 2010/2/26 Sergio Gurgel > Bom dia Pessoal. > > Estou tendo que configurar um roteador em um cliente na qual o link de > internet é PPPoa(*PPPoA (point-to-point protocol over AAL5 - ou over ATM)* > é > uma adaptação do PPP para funcionar em redes ATM (ADSL). > Alguém tem um script para discagem para esse tipo de conexão? > > Obrigado. > > Atenciosamente, > > Sérgio Gurgel > http://br.linkedin.com/in/sergiogurgel > twitter: @sergiogurgel > > "o mal do inteligente é achar que o outro é burro!" > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > -- Danilo Gonçalves Baio (dbaio) - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] 2 links (Velox e Virtua) no freebsd
> carp não é usado para redundância entre 2 ou mais servidores? > > creio que no caso dele é exatamente igual ao tópico que foi discutido > ontem[1]! > > > Abraços > > [1] http://www.fug.com.br/historico/html/freebsd/2010-02/msg00518.html No caso, acho que o melhor seria utilizar um protocolo de roteamento, talvez RIP uma vez que é a única coisa falada por modems ADSL. Sugeriria usar o quagga. -- []´s Helio Loureiro http://helio.loureiro.eng.br http://hloureiro.multiply.com http://twitter.com/helioloureiro - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] 2 links (Velox e Virtua) no freebsd
carp? carp não é usado para redundância entre 2 ou mais servidores? creio que no caso dele é exatamente igual ao tópico que foi discutido ontem[1]! Abraços [1] http://www.fug.com.br/historico/html/freebsd/2010-02/msg00518.html -- From: "Franklin França" Sent: Friday, February 26, 2010 8:05 PM To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)" Subject: Re: [FUG-BR] 2 links (Velox e Virtua) no freebsd > CARP+Pf++Pfsync+ifstated > > > Em 26 de fevereiro de 2010 19:56, Anderson Alves de Albuquerque < > anderso...@gmail.com> escreveu: > >> uma solucao sem pfsense seria possivel? onde eu montaria na mao tudo? >> >> 2010/2/26 mantunes >> >> > tb. >> > >> > Em 26 de fevereiro de 2010 19:40, irado furioso com tudo >> > escreveu: >> > > Em Fri, 26 Feb 2010 19:32:43 -0300 >> > > Anderson Alves de Albuquerque , conhecido >> > > consumidor/usuário de drogas (Windows e BigMac com Coke) escreveu: >> > > >> > >> >> > >> Como eu poderia montar um firewall com dois links, sendo um Virtua >> > >> e >> > >> outro Velox, de forma que os dois links funcionem ao mesmo tempo? >> > > >> > > sugiro o pfSense. >> > > >> > > -- >> > > saudações, >> > > irado furioso com tudo >> > > Linux User 179402/FreeBSD BSD50853/FUG-BR 154 >> > > Não uso drogas - 100% Miko$hit-free >> > > "Chama-se tirano o rei que não conhece outras leis senão os seus >> > > caprichos." (Voltaire) >> > > - >> > > Histórico: http://www.fug.com.br/historico/html/freebsd/ >> > > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >> > > >> > >> > >> > >> > -- >> > Marcio Antunes >> > Powered by FreeBSD >> > == >> > * Windows: "Where do you want to go tomorrow?" >> > * Linux: "Where do you want to go today?" >> > * FreeBSD: "Are you, guys, comming or what?" >> > - >> > 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 >> > > > > -- > atenciosamente, > > Franklin de França > - > 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] Bloqueio Gtalk no PF
Acordei bonzinho e resolvi compartilhar com vcs!! Fiz na mão então
DEVE ter erros de sintaxe. Segue abaixo:
#named.conf
acl permitidos {
192.168.1.1;192.168.1.2;
};
view "gtalk_liberado" {
match-clients { permitidos; };
zone "." {
type hint;
file "named.root";
};
zone "" {chatenabled.mail.google.com
type forward;
forwarders { 8.8.8.8;8.8.8.4;}
};
};
view "gtalk_bloqueado" {
match-clients { any; };
zone "." {
type hint;
file "named.root";
};
zone "chatenabled.mail.google.com" {
type master;
file "chatenabled.mail.google.com.db";
};
};
###
chatenebaled.mail.google.com.db
$TTL 3600
@ SOA chatenabled.mail.google.com. root.chatenabled.mail.google.com. (
201002271 ; serial
10800 ; refresh (3 hours)
3600 ; retry (1 hour)
1814400; expire (3 weeks)
86400 ; minimum (1 day)
)
NS ns.chatenabled.mail.google.com.
* IN A 127.0.0.1
ns IN A 127.0.0.1
Em 26 de fevereiro de 2010 23:05, Giancarlo Rubio
escreveu:
> Criando uma zona falsa de dns para esse dominio, dentro de uma view que
> permita somente esses ips de usarem ela.
>
> Em 2 26, 2010 10:48 PM, "Watanabe Anderson" escreveu:
>
> Pessoal,
>
>
> Eu mesmo já havia visto esse lance de bloquear pelo DNS, mas, não compreendi
> e nem entendi como é implementado.
>
> Pesquise, mas não encontrei nada que me orientasse nesse sentido.
>
>
> Alguém pode me ajudar? Podem postar como fazer isso pelo DNS e liberar
> somente os ips que podem acessa-lo?
>
>
> Grato,
> Anderson.
>
>
> --
> From: "Renato Botelho"
> Sent: Saturday, February 27, 2010 4:35 AM
>
> To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"
> Subject: Re: [FUG-B...
>
>> 2010/2/26 Giancarlo Rubio : >> Vc está supondo isso
>> ou vc fez o teste? > > Bl...
--
Giancarlo Rubio
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] Fwd: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-10:02.sched_ule
-- Forwarded message -- From: FreeBSD Errata Notices Date: 2010/2/27 Subject: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-10:02.sched_ule To: FreeBSD Errata Notices -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 = FreeBSD-EN-10:02.sched_ule Errata Notice The FreeBSD Project Topic: Deadlock in ULE scheduler Category: core Module: kern Announced: 2010-02-27 Credits: Attilio Rao Affects: FreeBSD 7.0, 7.1, and 7.2. Corrected: 2009-09-24 09:08:22 UTC (RELENG_7, 7.2-STABLE) 2010-02-27 10:55:43 UTC (RELENG_7_2, 7.2-RELEASE-p7) 2010-02-27 10:55:43 UTC (RELENG_7_1, 7.1-RELEASE-p11) For general information regarding FreeBSD Errata Notices and Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit http://security.freebsd.org/>. I. Background FreeBSD has two schedulers: the classic 4BSD scheduler and a newer, more SMP-aware scheduler called ULE. The 4BSD scheduler was the default scheduler until FreeBSD 7.0. Starting with FreeBSD 7.1 the default scheduler is ULE. The scheduler is responsible for allocating CPU time to threads and assigning threads to CPUs. Runnable threads (i.e. threads which are not waiting for a blocking operation, such as an I/O operation, memory allocation or lock acquisition, to complete) are assigned to a CPU and placed in that CPU's run queue. Each thread and each CPU's run queue is protected by a separate lock. II. Problem Description When a thread is reassigned from one CPU to another, the scheduler first acquires the thread's lock, then releases the source CPU's run queue lock. The scheduler then acquires the target CPU's run queue lock and holds the lock while it adds the thread to the queue and signals the target CPU. Finally it reacquires the source CPU's run queue lock before unlocking the thread. A thread on the target CPU, having been notified of the reassigned thread's arrival on the target CPU's run queue, will then acquire the thread's lock before switching it in. If, at the same time, a third thread tries to acquire both the source and target CPUs' run queue locks, a three-way deadlock may occur: - The second thread has acquired the target CPU's run queue lock, but has not yet acquired the first thread's lock. - The third thread has acquired the source CPU's run queue lock, and is waiting to acquire the target CPU's run queue lock, which is locked by the second thread. - The first thread is waiting to acquire the source CPU's run queue lock, which is held by the third thread, in order to release its own lock. As a result both CPUs' run queues are locked, and each of the three threads is waiting to acquire a lock held by one of the others. Eventually every CPU in the system ends up in a state where it is waiting to acquire each other's locks. It has not been determined whether this also affects single-CPU systems but it is recommended this Errata Notice be applied to single-CPU systems as well. III. Impact Affected systems may become deadlocked and require power-cycling. The chance of a deadlock occurring increases with the number of CPUs. There may be other aggravating factors such as running powerd(8). But eventually any multi-processor system using the ULE scheduler will become deadlocked. IV. Workaround Replace SCHED_ULE with SCHED_4BSD in your kernel configuration, recompile your kernel and reboot the system. Note that systems running the 4BSD scheduler are not affected; to determine what scheduler a system is using, run # sysctl kern.sched.name V. Solution Perform one of the following: 1) Upgrade your system to 7-STABLE, or to the RELENG_7_2 or RELENG_7_1 security branch dated after the correction date. 2) To patch your present system: The following patches have been verified to apply to FreeBSD 7.1 and 7.2 systems. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch http://security.FreeBSD.org/patches/EN-10:02/sched_ule.patch # fetch http://security.FreeBSD.org/patches/EN-10:02/sched_ule.patch.asc b) Apply the patch. # cd /usr/src # patch < /path/to/patch c) Recompile your kernel as described in http://www.FreeBSD.org/handbook/kernelconfig.html> and reboot the system. VI. Correction details The following list contains the revision numbers of each file that was corrected in FreeBSD. CVS: Branch Revision Path - - RELENG_7 src/sys/kern/sched_ule.c 1.214.2.9 RELENG_7_2 src/UPDATING 1.507.2.23.2.1
