Warto pakować się w 802.11n?
styczeń 17, 2008, godzina 23:01 · Sieci bezprzewodowe, Technologia »
Zrobiłem w swoim życiu kilka błędów w dziedzinie kupowania elektroniki. W sumie jak dotąd nie kupiłem kompletnie beznadziejnego urządzenia, ale kupiłem rzeczy, które okazały się nie dość dobre - zwłaszcza po pewnym okresie użytkowania. Nie mogę sobie wybaczyć, że gdy kupowałem jakiś czas temu router to kupiłem wersję pozbawioną sieci bezprzewodowej. Dlaczego? Po pierwsze dlatego, że wtedy to jeszcze było tuż przed rozkwitem technologii Wi-Fi, więc urządzenie było droższe nieco (ale w sumie niewiele o ile pamiętam), za to z drugiej strony powiedziałem sobie “ale ja nie mam żadnego urządzenia obsługującego Wi-Fi, po co mi to?!”.
Dzisiaj posiadam trzy urządzenia mające łączność sieci bezprzewodowej w standardach 802.11b/g. I zastanawiam się nad kupnem routera bezprzewodowego, a raczej - i przewodowego i bezprzewodowego, który ma zastąpić mojego starego już D-Linka DI-504. Popatrzyłem trochę po sklepach komputerowych i stwierdzam, że coraz więcej urządzeń widać, które mają wsparcie dla póki co drafu technologii 802.11n. Czyli wykorzystującej MIMO wersji sieci bezprzewodowej, w której transfery mogą osiągać ponoć 180 Mb/s. To jest wielkość fajna, bo większa znacznie od tego, co oferuje używany przeze mnie Fast Ethernet, który zużywam czasami (rzadko to rzadko…) do granic wysycenia kabla sieciowego.
Dzisiaj rano gdy powiedziałem znajomemu o moich chęciach zakupu routera z obsługą “enki”, on zapytał: “a czy masz jakikolwiek sprzęt obsługujący 802.11n?”. Hm, czy nie przypomina to pytania które podałem na wstępie? Tak, nie mam żadnego urządzenia, które obsługiwało by 802.11n. Ale na szczęście ten standard jest kompatybilny wstecz, więc moje urządzenia (z których jedno chyba obsługuje tylko “b”) będą działać. Z drugiej strony można liczyć, że gdy wreszcie pojawi się finalna wersja standardu 802.11n, bo to co mamy na razie to draft, czyli szkic projektu, to pojawi się także aktualizacja firmware, dzięki której będzie można korzystać z ostatecznej wersji standardu sieci.
Jest jeden, mały problem. A raczej spory problem, jest nim cena sprzętu o którym myślę, czyli Linksys WRT350N. 500 PLN, podczas gdy urządzenie oparte o 802.11g i bez funkcji NAS można nabyć za znacznie mniej. Z jednej strony NAS to jest fajna sprawa (dysk podłączony przez USB posiadam, pudełka z samą funkcją NAS nie chciał bym kupić, a tutaj ten Linksys umie te udziały sieciowe udostępniać po SMB), a także nie chciał bym pewnego dnia się obudzić w świecie, gdzie każdy ma “n”.
Nie mam pomysłu, na razie może poczekam aż mój wypatrzony sprzęt stanieje, albo pojawi się coś podobnego u konkurencji…
Permalink |
procmail czyli oszczędzanie sobie pracy
styczeń 13, 2008, godzina 14:34 · Linux, Technologia »
Czy e-mail nie jest jednym z najważniejszych narzędzi używanych do kontaktu? U mnie tak, chociaż jego rolę bardzo przejęły komunikatory internetowe odkąd się pojawiły. Niemniej e-mail pozostaje ważny - ja bardzo często z jego użyciem wysyłam pliki, kontaktuję się z różnymi osobami i tak dalej. Przede wszystkim także odbieram powiadomienia, logi, listy dyskusyjne (bo są jeszcze na świecie serwisy nie posiadające RSS), bo jak widzę to to staje się najpopularniejsze.
Oczywiście najgorszym problemem pozostaje sortowanie e-maili, a zwłaszcza usuwanie spamu. Dziennie dostaję kilkanaście wiadomości będących kompletnymi śmieciami. Moje jednak wszystkie konta pocztowe przekierowywane są na GMail, którego filtr antyspamowy odsiewa większość niechcianych informacji. Jaka jest jednak druga linia obrony? Są nią oczywiście filtry antyspamowe w programie pocztowym (ja używam Microsoft Office Outlook w wersji 2003) oraz to, o czym mam zamiar dzisiaj pisać - filtry na poziomie serwera pocztowego, pomiędzy odebraniem poczty i przekierowaniem jej dalej na mój adres na GMailu.
Mój serwer pocztowy jest jednocześnie serwerem HTTP i kilku innych usług - najważniejsze jest jednak to, że posiadam dostęp do konsoli oraz do programu procmail. O procmailu dowiedziałem się niejako przypadkiem, nie mając nigdy głębszej styczności z administracją serwerami opartymi o Uniksa czy Linuksa, i procmail przypadł mi do gustu bardzo szybko.
Najpierw jak wygląda przekierowanie poczty. U mnie obsługą poczty zajmuje się Postfix, którego pliki konfiguracyjne /etc/aliases i /etc/postifx/virtual definiują aliasy (prawdziwe lub wirtualne adresy e-mail). Kilka aliasów wirtualnych oraz kont bardziej “rzeczywistych” jest przekierowywanych na moje konto użytkownika w systemie. A dalszą obsługą zajmuje się ukryty plik w moim katalogu domowym, .forward o następującej treści:
"|IFS=' '&&exec /usr/bin/procmail -f-||exit 75 #ktos"
Który to przekierowuje przychodzące e-maile do procmaila właśnie. Cała konfiguracja procmaila jest z kolei zapisana w kolejnym ukrytym pliku w katalogu domowym, .procmailrc, w którym definiujemy reguły, które mają być zastosowane do wiadomości. Ja, w tworzeniu mojego liku reguł skorzystałem z wszechwiedzy Internetu, a zwłaszcza wprowadzania do procmaila Łukasza Komsty - oraz częściowo z książki z której o procmailu się dowiedziałem - “Zarządzanie czasem. Strategie dla administratorów systemów.”.
Do rzeczy - jak wygląda mój .procmailrc? Wygląda on tak:
# włączenie logowanie
LOGFILE=/home/ktos/logs/procmail.log
ABSTRACT=no
VERBOSE=no
# potrzebne później
TIME=`date +%H%M`
ISGT=`expr ${TIME} \> 0900`
ISLT=`expr ${TIME} \< 1700`
# mantis-mamdom i automatyczny sposób zarządzania zgłoszeniami
:0
* ^to.*mantis-mamdom
mantis-mamdom.mbox
# całą kopię następnych mejli wrzucaj do pliku kopii zapasowej
:0 c
Backup.mbox
# w momencie gdy jest to poczta od demonów i takich tam,
# wrzuć do oddzielnego pliku
:0 c
* ^FROM_MAILER
Daemons.mbox
# specjalny adres administracyjny
:0 c
* ^To.*administrator@[ciach, pewna domena]
Admin.mbox
:0
* ^Subject.*Undelivered.Mail.Returned.to.Sender
Daemons.mbox
:0
* .*Postfix.*host.*[ciach, pewien host]
Daemons.mbox
# w momencie gdy jest to poczta zawierająca pewne slowa w
# temacie wskazujace na spam to wyrzuc to oddzielnego
# pliku i nie przekazuj dalej
:0
* ^Subject:.*free|^Subject:.*dick|^Subject:.*girl|^Subject:.*cheap|^Subject:.*f.ck|^Subject:.*adult
Spam.mbox
# gdy jest to ważna poczta
# powiadom smsem jeżeli jest w godzinach 9-17
:0 c
* ^From.*[ciach, nieistotne]|^To.*[ciach, prywatna wiadomość]
* ISGT ?? ^^1^^
* ISLT ?? ^^1^^
{
SUBJECT=`formail -x Subject: | cut -c -50`
:0
| /home/ktos/scripts/sms.py param [ciach, mój numer telefonu] Leia "New mail: ${SUBJECT}"
}
# wszystko co się nie łapie, jest forwardowane na mój główny e-mail
:0
! [ciach, nieważne]
Musiałem “wyciachać” tutaj wszystkie bardziej prywatne informacje, ale po prostu chodzi o ideę, nie o to jak mi zaspamować skrzynkę.
Pierwsze linie odpowiadają za logowanie. Logi są przydatne gdy coś z regułami się namiesza - wtedy widać co procmail zrobił z daną wiadomością. Ja też często patrzę na dół logów żeby zobaczyć czy jakaś określona wiadomość już doszła. Potem są już poszczególne reguły, które jak widać zaczynają się ciągiem :0. Pojawia się też :0 c, które oznacza, że w momencie gdy reguła zostanie spełniona to i tak system nadal przejdzie dalej tworząc kopię wiadomości.
mantis-mamdom i automatyczny system zarządzania zgłoszeniami to po prostu zapisywanie e-maili wysłanych pod specjalny adres do specjalnego pliku, który potem jest analizowany przez napisany przeze mnie skrypt w PHP i na jego podstawie są tworzone nowe zgłoszenia w systemie zarządzania zgłoszeniami Mantis. Potem jest zapisywanie wszystkich wiadomości do pliku backupu - po czym system tworzy kopię i idzie dalej. E-maile od demonów, mailerów, z tematem “Undelivered mail returned to sender” czy wysłane przez mojego Postfiksa zapisywane są do oddzielnego pliku poczty Daemons.mbox (właśnie sobie zdałem sprawę, że mam tam reguły, które dało by się zapisać w jednej chyba). Poczta idąca na adres administracyjny jest zapisywana w pliku Admin.mbox.
Fajniej zaczyna się robić potem. Najpierw jest reguła, która choć banalna, to likwiduje większość ostatnio trafiającego do mnie spamu. Nie wiem co się stało, ale e-maile z tematami zawierającymi “girls” czy “cheap” - i to nie udziwnionymi, są ostatnio częste. Więc taki filtr spokojnie je wycina - ja nie dostaję e-maili po angielsku, więc reguła doskonale się sprawdza ;-)
Następna rzecz jednak jest chyba jedną z fajniejszych. Jest to wykorzystanie skryptu do wysyłania SMS napisanego w Pythonie przez Marcina Pośpiecha lekko przeze mnie zmodyfikowanego (ale to nieważne, jedyną różnicą jest słowo “param” w parametrach, którego w “oficjalnej” wersji nie ma) oraz formaila. Działa to w ten sposób, że jeżeli są spełnione dwa warunki: jest pomiędzy godziną 9 i 17 oraz jest to poczta wysłana od specjalnych nadawców lub na mój specjalny prywatny adres, to system wysyła wiadomość SMS na mój numer, informując mnie o temacie nowej wiadomości - gdzie temat wiadomości jest “wycinany” z użyciem programu formail właśnie. Wygodne, bo spersonalizowane - dawno temu gdy miałem powiadomienie o nowej poczcie przez SMS (na plusnet.pl) to bardzo brakowało mi możliwości filtrowania tych powiadomień (ze spamu głównie).
Ostatnia linia załatwia wiadomości ostatecznie przekierowując wszystkie na moje inne konto pocztowe :-)
Potem za sprawę bierze się jeszcze program pocztowy sortując wiadomości na podstawie tematów i nadawców, wrzucając np. logi z crona wysyłane co tydzień do odpowiedniego katalogu “Logi”, a powiadomienia z różnej maści serwisów społecznościowych do folderu “Społecznościowe”.
Co to daje? To daje to, że nie muszę się zastanawiać, nie muszę przeglądać dziesiątek e-maili wyławiając z nich istotne informacje, a mam je od razu podane na tacy - gdy potrzebuję znaleźć pewną istotną wiadomość nie tylko mogę sięgnąć do archiwum mojego GMaila, ale także do odpowiednich plików w moim katalogu domowym na serwerze. Nie wspominając już o tym, że niektóre foldery Outlooka synchronizuję także z Pocket Outlookiem na moim PDA.
Technorati Tags: procmail, Linux, e-mail, filtering, procmailrc, Outlook, spam
PS. Nie mogę się zebrać do redesignu “Notatek”, a jak patrzę na styl CSS bloków kodu, to aż mi niedobrze…
Permalink |