Archiwum kategorii ‘Poczta’

Mailgraph – problem w nowym roku

poniedziałek, 5 Styczeń 2009

mailgraph

WARNING: ignoring future date in syslog line: [...]

Mailgraph wyraźnie nie radzi sobie ze zmianą roku. A dokładnie z sytuacją, gdy w pliku z logami znajduje się jednocześnie zapis ze starego roku i z nowego – jest tylko miesiąc i dzień, nie ma roku, więc Mailgraph nie domyśla się, że nastąpiła zmiana.

[...]
Dec 31 23:55:04 mail-gw postfix/qmgr[2768]: 7CB452E6CD: removed
Jan  1 00:00:03 mail-gw postfix/pickup[17295]: 12C25575BF: uid=0 from=<root>
[...]

Być może pierwszy raz w nowym roku mu się uda, następny nie, bo zaczyna się analiza od początku pliku, a to już data daleko w przyszłości (parametr --year domyślnie ma wartość bieżącego roku).

Doraźnym rozwiązaniem jest wycięcie z pliku zapisów starego roku i przetworzenie go raz jeszcze przez Mailgraph.

Publikacja adresów e-mail na stronie WWW

czwartek, 9 Październik 2008

Publikacja adresów e-mail na stronie WWW to ogólnie nie jest to dobry pomysł. Oczywiście stwierdzenie, że nie powinno się tak robić nie jest odkrywcze. Zalecenia znaleźć można na stronach ‘webmasterów’ (np. publikowanie małych obrazów czy flash).

Ja trochę inaczej. Poniżej statystyki z serwera pocztowego, który obsługuje takie adresy. Są one publikowane na głównej stronie (łącznie 4 szt.) od około pół roku. Na ok. 80 wiadomości przyjmowanych codziennie (bardzo mały serwer) przypada ponad 1800 wiadomości z różnych względów odrzucanych!

(Lotus Domino| FortiGate Multi-Threat Security Systems) Administrator

wtorek, 7 Październik 2008

Ukończyłem D8760PL, wiem nieco więcej, ale im głębiej zanurzałem się w to zagadnienie, tym bardziej byłem przekonany, że samowolnie nie wdrożę tego nigdzie.
Lotus Domino jest fajny, ma mnóstwo wodotrysków, a gdyby cały świat komunikował się za pomocą jego protokołu (chyba NRPC – Notes Remote Procedure Call), a nie SMTP, to byłoby w ogóle niesamowicie. Może gdybym miał okazję pracować w instytucji, która wykorzystuje co najmniej 50% jego mocy, to bym się przekonał do niego i zmienił zdanie, ale dla 60 osób to trochę ‘armata na wróbla’.

Poza tym chyba nie mogę uciec od projektów OpenSource, układania ‘klocków’ samemu i edytowania milionów plików, żeby cokolwiek działało ;-)

Miałem trochę zastrzeżeń do prowadzącego, ale przelałem to wcześniej na formularz, więc publicznie (tutaj) więcej nie piszę.

Inne zdanie mam o Bartoszu ‘de facto’ Niepsuj, który prowadził FortiGate Multi-Threat Security Systems I – Administration and Content Inspection w Compendium. Dobrze przygotowany merytorycznie, nie było dla niego trudnych pytań i ogólnie sprawiał miłe wrażenie.

Same szkolenie – podobnie jak poprzednie, utwierdziło mnie w przekonaniu, że kiedyś robiłem kawał dobrej roboty (pozdrowienia dla ‘bandy ruterowców’ od jej herszta).
Rozwiązania ze względu na cenę pewnie bym nie wybrał jako zwykłego routera, ale skoro jest wielkim kombajnem, to będę się starał wykorzystać maksymalnie jego możliwości. Bardzo obiecująco wygląda połączenie z Microsoft Active Directory (uwierzytelnianie przy NAT i zestawianie tuneli PPTP) – myślę, że będzie to pierwsza rzecz, jaką ‘rozklikam’ po powrocie. Na szkoleniu jedynie jest wzmianka o tym, ale korzysta się z lokalnej bazy użytkowników. Ćwiczyć nie ma co, bo baza użytkowników jest bazą, kwestia połączenia do niej to jedyna różnica.

Urządzenia FortiGate jako takie mają dokładnie taką samą funkcjonalność, niezależnie czy jest to SOHO czy Enterprise. Różnią się tylko ilością pamięci i mocą procesora, a co za tym idzie, możliwą do obsłużenia ilością sesji. Warto to wiedzieć kupując taki sprzęt.
Zarządzanie przez przeglądarkę daje nam możliwość edycji jakichś 20% opcji (wg szkoleniowca), więc niezbędne będzie poznanie CLI.
Zachwyciła mnie jeszcze wirtualizacja (na tym poziomie szkolenia jest jedynie informacja, że jest). W poprzedniej firmie widziałbym nawet z tego jakieś profity.

Jutro egzamin FCNSA. Zdajemy jako pierwsi w Polsce wg nowego systemu, cokolwiek to znaczy. Połowa z nas obawia się trudności językowych, ale jakoś to będzie :>

SQLgrey support for DBCluster

poniedziałek, 28 Lipiec 2008

Próbowałem uruchomić SQLgrey w połączeniu z wieloma (>1) bazami danych MySQL, ale nie wyszło. Niemniej poniżej moje doświadczenia:

  • bazy tylko do odczytu (read_hosts) muszą nasłuchiwać na domyślnym porcie (3306), nie ma innej możliwości konfiguracji,
  • $DBIx::DBCluster::CLUSTERS = {
    "$self->{sqlgrey}{db_host}" => {
    'WRITE_HOSTS'  => [$self->{sqlgrey}{db_host}],
    'READ_HOSTS'   => [@read_hosts],
    },
    };
  • połączenie na takiego samego użytkownika i to samo hasło jak baza podstawowa (db_host)
$self->{sqlgrey}{dbh} = DBIx::DBCluster->connect($self->cnctinfo(),
$self->{sqlgrey}{db_user},
$self->{sqlgrey}{db_pass},
{ PrintError => 0,
AutoCommit => 1,
InactiveDestroy => 1 }
)
or $self->mylog('dbaccess', 0, "can't connect to DB: $DBI::errstr");

O ile z użytkownikiem i hasłem nie ma problemu (baza mysql również się replikuje na serwer zapasowy), to z portem jak najbardziej jest, no ale można się dostosować.

  • pożyteczną opcją może być db_cleanup_hostname, która zapewnia, że tylko jeden serwer z SQLgrey będzie wykonywał okresowe czyszczenie tabel. W przypadku, gdy mamy spory ruch (dużo rekordów w bazie) i wiele frontend‘owych serwerów pocztowych powinno to zmniejszyć obciążenie bazy, a negatywnego wpływu na pracę raczej nie ma.

Uruchomienie SQLgrey z DBCluster kończy się mniej więcej tak:

Jul 28 11:28:01 mailin-ng1 sqlgrey: dbaccess: Using DBIx:DBCluster
Jul 28 11:28:01 mailin-ng1 sqlgrey: dbaccess: Read_hosts: 10.0.27.176
Jul 28 11:28:01 mailin-ng1 sqlgrey: fatal: Can't locate object method "connect" via
 package "DBIx::DBCluster" at /usr/sbin/sqlgrey line 829.

DBIx::DBCluster w wersji 0.01. SQLgrey – 1.7.4. Perl 5.8.8.