Słuchajcie ja to zrobiłem w swoim projekcie bez squida. Działa to tak, że DNAtem zakładamy przekierowanie portu 80 na odpowiedni port apacha (wiadomo, standard). User otwiera stronkę komunikatu a php po jej otwarciu ściąga blokadę. Trzeba tylko dodać usera www-data do /etc/sudoers i pozwolić mu wykonywać polecenie iptables. Ściągnijcie sobie paczkę:

http://files.v-smart.pl/v-smart-2.0/router-vsmart-2.0.tar.gz

i zajrzyjcie do katalogu:

/var/v-smart/info/200

Tu jest treść komunikatu oraz mechanizm ściągania blokady.

W dniu 2011-09-14 16:36, Sarenka pisze:

On Wed, 14 Sep 2011 14:58:41 +0200, Jakub wrote:

...

Teoretycznie mi się udało zmieniłem wpis ten a href="index.php?readed=1&oldurl=http://moja domena.pl">{t}Click here to mark this message as readed.{/t}</a> I działa. Ale muszę to dokładnie sprawdzić bo rc.messages automatycznie się generuje co 5min i koleś jak włączył przeglądarkę to zamiast raz kliknac na komunikat to musiał ok 5 razy dopiero mu znikło powiadomienie.

Musisz mieć coś nie tak. Parę lat używałem właśnie takiej konfiguracji i wszystko śmigało. Zerknij do archiwum (tak ze dwa, może trzy lata wstecz) - wrzucałem na listę moje skrypty.

On Mon, 10 Oct 2011 09:27:28 +0100, Bartek Swedrowski bartek@idk.net.pl wrote:

A ja zrobiłem to jeszcze inaczej - nie chcieliśmy wszystkiego puszczać przez Squida jako że takowego nie mieliśmy i nie chcieliśmy mieć w sieci. Kolejna rzecz do pilnowania - po co.

Regułki DNAT przy ok 1000 klientów zaczynają robić się dosyć męczące i ciężkie do jakiegokolwiek debuggingu.

Za to od razu mieliśmy serwery DNS w sieci, do których dodaliśmy kolejny "view" do którego kierowane są zapytania tylko z adresów IP klientów którzy mają włączone powiadomienia. Lista IPeków to nic innego jak plik

tekstowy

który jest includowany i regenerowany co 5 min na podstawie 1 zapytania SQL.

Oczywiście od razu widać tutaj duży minus - w zależności od rekordów TTL

i

co jest zcachowane po stronie klienta, klienci nie od razu zobaczą powiadomienia - zależy jakie strony oglądają bądź jakie rekordy odpytują (też teoretycznie inne usługi mogą przestać działać, np. poczta jako że przykładowo rekord imap.gmail.com ma tylko 300 sekund TTL). Ale w praktyce działa to bardzo fajnie, przede wszystkim "strona" z powiadomieniem nie jest DoSowana w momencie w którym wyślesz powiadomienia do klientów a ludzie którym coś tam przestaje działać, od razu sprawdzają czy coś w przeglądarce działa i widzą powiadomienie. Klikają "przeczytałem" i dostają licznik czasu w dół od 5 minut - bardzo efektowany "wkurzacz" podbijający termin płatności ;-)

A klient ustawi sobie dns-y google 8.8.8.8 i 8.8.4.4 i powiadomienie nie będzie działać :-)

On Mon, 10 Oct 2011 09:56:17 +0100, Bartek Swedrowski bartek@idk.net.pl wrote:

2011/10/10 Dariusz Kowalczyk dariusz.kowalczyk@webvisor.pl

...

A klient ustawi sobie dns-y google 8.8.8.8 i 8.8.4.4 i powiadomienie

nie

...

będzie działać :-)

E-e.

DNSy zewnętrzne blokowane dla indiwidualnych użytkowników defaultowo ;-)

A nawet jakby, nie ma co męczyć się nad rozwiązaniem 100%, 90%

wystarczy.

A jakim to prawem blokujesz dostęp do części netu klientom? Czy o ni o tym wiedzą że mają wykastrowany internet ?

2011/10/10 Tomasz Chiliński tomasz.chilinski@chilan.com

Poczytaj o ipset.

Czytałem a nawet wstępnie zaimplementowaliśmy ale wtedy był problem że jeżeli wyślesz powiadomienie do 1000 użytkowników to masz ładnego dos'a na serwer co serwuje powiadomienia.

Absolutnie system który mamy nie jest najlepszy ale jest to może kolejny który nie używa Squid'a więc pomyślałem że napiszę.

2011/10/10 Tomasz Chiliński tomasz.chilinski@chilan.com

A przy DNS nie ma? Przecież to nie DNS serwuje powiadomienia!

Nie, DNS serwuje odpowiedź z wskazaniem hosta który ma tablicę z powiadomieniem :) Czyli zamiast wp.pl wskazywać na 212.77.100.101 odpowie 192.168.0.1 z TTL dla tego rekordu 5 sekund.

Tak jak wcześniej pisałem, różnica w tym jakie rekordy ile są cachowane i jakie TTLe mają w sposób "naturalny" rozkłada obciążenie na dłuższy okres czasu.