Novell Netware w sieci Internet

W poprzednich dwu "odcinkach" cyklu traktującego o niekomercyjnym oprogramowaniu TCP/IP dla PC (Netforum 5/94 i 4/95) podłączaliśmy do sieci pojedynczy komputer. W niniejszym tekście spróbujemy zająć się problemem dołączenia do Internetu sieci lokalnej Novell Netware.

Już samo fizyczne wykonanie połączenia nie jest w tym przypadku sprawą oczywistą. O ile w przypadku pojedynczego PC połączenie zainstalowanej w komputerze karty sieciowej (względnie - w przypadku używania połączenia SLIP lub PPP - modemu) z odpowiednim kablem, który "gdzieś tam" łączy się z siecią Internet (w jaki sposób, to w tym momencie nie musi nas interesować), nie przysparza raczej żadnych wątpliwości, o tyle wobec dziesiątków komputerów, kart sieciowych i wtyczek oraz setek metrów kabli składających się na sieć lokalną nietrudno stanąć bezradnie. Aby dołączyć sieć lokalną do większej sieci, musimy oczywiście użyć routera. Możliwych jest tu kilka rozwiązań. Jeżeli w pobliżu istnieje już jakaś inna sieć lokalna przyłączona do Internetu (np. maszyn Unixowych), obie sieci - o ile nie są one zbyt duże - można bezpośrednio połączyć elektrycznie "na jednym kablu", czyniąc z jednej sieci przedłużenie drugiej (rys.1). Wówczas router, przez który podłączona była sieć Unixowa, będzie teraz obsługiwał również i sieć Novell. Rozwiązanie to może być jednakże zastosowane tylko dla bardzo małych sieci. Gdy sieci są zbyt duże, lub po prostu nie ma innej sieci, do której możnaby się przyłączyć, sieć Novell musi być wyposażona we własny router. Może nim być dedykowany do tego celu osobny komputer PC - wystarczy klasy 286 - z odpowiednim oprogramowaniem. Najczęściej w takich zastosowaniach wykorzystywany jest program o nazwie KA9Q (ta dziwna nazwa jest krótkofalarskim znakiem wywoławczym jego autora), który można znaleźć np. w archiwum Simtel: ftp://ftp.cyf-kr.edu.pl/pub/mirror/Simtel.Net/msdos/tcpip. Innym, bardzo chętnie stosowanym rozwiązaniem, jest użycie w charakterze routera samego serwera sieci Novell - moduł TCPIP.NLM, wchodzący standardowo w skład systemu Netware, realizuje między innymi taką właśnie funkcję. W obu przypadkach komputer pełniący funkcję routera musi być wyposażony w dwie karty sieciowe (rys.2): jedna z nich jest włączona w sieć lokalną, druga - dołączona do sieci TCP/IP połączonej z Internetem, w identyczny sposób jak dla pojedynczego PC. Trzeba tu zaznaczyć, że KA9Q potrafi obsługiwać "z drugiej strony" routera połączenia modemowe typu SLIP, podczas gdy w przypadku serwera Netware jest to niemożliwe - musi on być bezpośrednio przyłączony do sieci TCP/IP przez kartę sieciową.

Rozważając z kolei zagadnienie połączenia sieci Novell z Internetem od strony programowej, możemy wyróżnić dwa zupełnie odrębne problemy: połączenie z Internetem poszczególnych komputerów pracujących w sieci, a zatem umożliwienie korzystania na nich z aplikacji typu telnet, ftp, WWW itp., oraz połączenie z Internetem serwera sieci, co umożliwia uruchomienie na nim np. serwera ftp czy poczty elektronicznej. Realizacja każdego z tych celów jest możliwa niezależnie od drugiego (można więc np. mieć podłączone do Internetu tylko stanowiska robocze w sieci, albo tylko serwer), chociaż oczywiście największe możliwości uzyskuje się łącząc je razem.

Zajmijmy się najpierw kwestią podłączenia do Internetu komputerów pracujących w sieci Novell. Zasadniczym problemem jest tu umożliwienie jednoczesnego korzystania z tej samej karty sieciowej przez dwa niezależne od siebie programy: samą powłokę sieciową systemu Netware, używającą Novellowskiego protokołu IPX, oraz aplikacje Internetowe stosujące protokół TCP/IP. Potrzebne są w tym celu sterowniki kart sieciowych, dopuszczające "mieszanie" kilku protokołów na jednej karcie - takimi sterownikami są używane obecnie w Netware, w miejsce dawnego tzw. "monolitycznego" IPX-a, sterowniki typu ODI. W oparciu o te sterowniki działa firmowe rozwiązanie Novella - pakiet o nazwie LAN Workplace for DOS, na który składa się jądro TCP/IP wykorzystujące sterownik ODI oraz zestaw podstawowych aplikacji pracujących z tym jądrem (telnet, ftp, finger itd...). Pakiet ten nie jest jednakże jedyną możliwością udostępnienia Internetu komputerom PC pracującym w sieci Netware. Opracowany bowiem został specjalny packet driver, działający "ponad" sterownikiem ODI, którego załadowanie wraz ze standardowym zestawem programów obsługujących ODI (LSL, sterownik ODI dla danej karty, IPXODI i NETX) daje możliwość korzystania ze wszystkich opisywanych w poprzednich tekstach niekomercyjnych aplikacji Internetowych (a także np. z komercyjnego PC/TCP, również pracującego w oparciu o packet driver). Program ten nosi nazwę ODIPKT, napisany został przez Daniela Lanciani i dostępny jest jako public domain.

Packet drivery same w sobie również umożliwiają "mieszanie" kilku protokołów na jednej karcie, możliwe jest zatem również podejście odwrotne: zamiast specjalnego packet drivera "nad" sterownikiem ODI, używa się do bezpośredniej obsługi karty sieciowej zwykłego packet drivera dla danej karty, a Netware korzysta ze sterownika IPX działającego "nad" packet driverem, a nie nad ODI. Sterownik taki, o nazwie PDIPX, został wyprodukowany przez firmę Intel i jest dostępny jako freeware. Wielu administratorów sieci Netware podłączonych do Internetu, w sytuacjach, gdzie nie ma konieczności stosowania explicite sterowników ODI, preferuje jego użycie, ze względu na mniejszą ilość ładowanych do pamięci programów rezydentnych, a zatem i mniejszą zajętość pamięci stanowiska roboczego (w tym wariancie ładowane są tylko: packet driver dla danej karty, PDIPX i NETX). Z kolei przewagą wariantu z ODIPKT jest łatwiejsze przejście od istniejącej dotychczas "zwykłej" instalacji Netware, sprowadzające się do dodania wywołania jednego dodatkowego programu w plikach startowych komputerów pracujących w sieci.

Po udostępnieniu - jednym lub drugim sposobem - możliwości korzystania z packet drivera w komputerach będących klientami sieci Novell, instalacja aplikacji, takich np. jak NCSA Telnet, Minuet, czy Trumpet WinSock przebiega identycznie jak dla pojedynczego PC, z jedną różnicą: ponieważ każdy z komputerów musi mieć unikalny adres IP, a adres ten wpisuje się w plikach konfiguracyjnych instalowanych aplikacji, potrzebne byłoby dla każdego programu tyle plików konfiguracyjnych, ile jest komputerów w sieci, a na dodatek program musiałby być uruchamiany za pośrednictwem skomplikowanego pliku wsadowego, zapewniającego wybór pliku konfiguracyjnego odpowiedniego dla danego komputera. Aby oszczędzić sobie tych wszystkich komplikacji, zalecane jest zastosowanie centralnego przydziału adresów IP za pomocą przeznaczonego właśnie do takich zastosowań protokołu BOOTP. Możliwość korzystania z tego protokołu istnieje prawie we wszystkich współczesnych aplikacjach TCP/IP, tak komercyjnych, jak i niekomercyjnych. Działanie protokołu BOOTP polega na tym, że aplikacja zaraz po uruchomieniu wysyła do sieci specjalną ramkę typu broadcast, czyli adresowaną do wszystkich maszyn w sieci, stanowiącą swego rodzaju pytanie: "jaki jest mój adres IP?". Ramkę tę odbierają - jako się rzekło - wszystkie komputery w sieci lokalnej, ale odpowiada na nią tylko maszyna, na której pracuje specjalne oprogramowanie, tzw. serwer BOOTP. Serwer BOOTP zawiera tablicę przypisującą adresy IP do konkretnych komputerów w sieci (a ściślej rzecz biorąc, do konkretnych adresów hardware'owych kart sieciowych). Na jej podstawie (adresy mogą być także przydzielane dynamicznie z określonego przedziału wartości, w kolejności zgłaszania się komputerów) serwer BOOTP odsyła pytającemu komputerowi pakiet zawierający jego adres IP, a także inne dane niezbędne do poprawnej pracy w sieci, jak maskę, adres IP najbliższego routera i adres IP nameserwera. W oparciu o te dane oprogramowanie TCP/IP może się właściwie skonfigurować i rozpocząć normalną pracę. Jeżeli do sieci Novell bezpośrednio fizycznie dołączona jest maszyna Unixowa, może ona posłużyć za serwer BOOTP; możliwe jest także zainstalowanie oprogramowania BOOTP na serwerze Netware (zob. dalej).

Jak wspomniano powyżej, umożliwienie dostępu do TCP/IP w stanowiskach roboczych sieci niekoniecznie musi się wiązać z podłączeniem do Internetu samego serwera Netware. Jeżeli serwer nie jest wykorzystywany jako router, ani też jako serwer BOOTP (funkcje te może pełnić np. znajdująca się w sieci maszyna Unixowa), może on pracować identycznie jak w izolowanej instalacji Netware, nie będąc w żaden sposób "świadomy" tego, że w sieci oprócz pakietów IPX przesyłane są również pakiety IP. Na poszczególnych stanowiskach w sieci można natomiast korzystać z aplikacji Internetowych w identyczny sposób, jak na "wolnostojącym" PC z zainstalowanym packet driverem.

Zainstalowanie TCP/IP na serwerze sieci pozwala na dodanie nowych możliwości, niedostępnych dla pojedynczego PC, a znanych dotąd przeważnie tylko z komputerów Unixowych. Przede wszystkim możliwe jest wysyłanie i odbieranie poczty elektronicznej bezpośrednio przez użytkowników sieci Novell, bez konieczności posiadania skrzynek pocztowych na jakichkolwiek innych komputerach. Można uruchomić serwer ftp (także z kontem "anonymous"), gophera, a nawet http (World Wide Web). Wreszcie, możliwe jest zainstalowanie oprogramowania NFS - zarówno klienta (możliwość korzystania przez sieć z dysków innych maszyn, z reguły Unixowych), jak i serwera (udostępnianie dysków Netware innym komputerom). Niestety, dla realizacji tych ostatnich usług dostępne są wyłącznie firmowe pakiety Novella - Netware NFS i Netware NFS Gateway - których bardzo wysoka cena stanowi istotne ograniczenie zakresu ich potencjalnego zastosowania.

Pierwszym krokiem niezbędnym dla udostępnienia wspomnianych możliwości jest uruchomienie na serwerze modułu TCPIP.NLM, wchodzącego w skład standardowego systemu Netware (możliwość obsługi TCP/IP istnieje w systemie Netware od wersji 3.11 wzwyż). Moduł ten spełnia funkcję jądra TCP/IP i jest niezbędny do pracy jakichkolwiek aplikacji Internetowych. Trzeba przy tym dokonać pewnych modyfikacji w pliku startowym AUTOEXEC.NCF serwera, aby "widział" on w sieci oprócz pakietów IPX pakiety IP. Przykładowy fragment pliku AUTOEXEC.NCF, w przypadku gdy serwer pracuje równocześnie jako router, może wyglądać jak poniżej:

load 3c509 port=300 frame=ETHERNET_802.3 name=ipx1
load 3c509 port=300 frame=ETHERNET_II name=ip1
load 3c509 port=310 frame=ETHERNET_II name=ip0
load tcpip forward=yes rip=yes
bind IPX to ipx1 net=11
bind IP to ip0 addr=149.156.24.10 mask=255.255.255.224 gate=149.156.24.1
bind IP to ip1 addr=149.156.25.1 mask=255.255.255.224

Przyjrzyjmy się teraz dostępnemu oprogramowaniu pozwalającemu realizować usługi Internetowe na tak przygotowanym serwerze. Szeroko znana jest wśród użytkowników sieci Novell połączonych z Internetem seria darmowych programów opracowanych przez grupę czeskich programistów z politechniki w Pradze, występującą pod nazwą HellSoft. Wśród tych produktów na czoło wysuwa się bardzo dobrze opracowany serwer ftp. Pozwala on na otwarcie sesji ftp na konto dowolnego użytkownika Netware - oczywiście z uwzględnieniem wszystkich standardowych praw dostępu (zaimplementowana jest także obsługa konta "anonymous") - i to nie tylko na tym serwerze, na którym program jest zainstalowany, ale także na ewentualnych innych serwerach w tej samej sieci Novell, przy czym nie muszą one do tego celu mieć załadowanego modułu TCPIP.NLM! Możliwa jest obsługa w ten sposób także serwerów pracujących pod kontrolą starych wersji Netware (2.xx). Program wyposażony jest w "inteligentny" algorytm odnajdywania macierzystego katalogu użytkownika, który się zalogował, ma również bardzo bogate możliwości konfiguracji, włącznie z selektywnym blokowaniem dostępu do poszczególnych kont dla połączeń z określonymi grupami adresów domenowych lub IP. Serwer ftp używa Unixowej składni nazw plików i podkatalogów, traktując poszczególne woluminy Netware jako katalogi najwyższego poziomu, bezpośrednio w "wirtualnym" katalogu głównym (tak więc np. plik, który w notacji Netware zapisujemy jako sys:users\guest\readme.txt, przez ftp dostępny będzie pod nazwą /sys/users/guest/readme.txt). Przy "ręcznym" używaniu klienta ftp serwer spełnia swoje zadanie znakomicie, jednak w dobie powszechnego korzystania z usług Internetowych wykorzystujących protokół ftp w sposób automatyczny (np. gopher, archie, WWW) ujawniają się dwie wady tego serwera, utrudniające bądź uniemożliwiające jego stosowanie w takim kontekście. Pierwszą usterką jest fakt, iż w przeciwieństwie do wszystkich Unixowych serwerów ftp, które po zalogowaniu się na konto "anonymous" lokują użytkownika w pozornym katalogu głównym (fake root directory), ukrywając rzeczywistą strukturę dysku, serwer HellSoftu ustawia jedynie macierzysty katalog przypisany użytkownikowi "anonymous" jako bieżący, nie traktując go jako katalogu głównego dysku. Tymczasem niektóre systemy korzystające automatycznie z ftp, takie jak gopher czy archie, zakładają "na sztywno", że po zalogowaniu się na konto "anonymous" katalogiem bieżącym jest katalog główny. W efekcie generują one nieprawidłowe ścieżki dostępu, co owocuje np. niemożliwością "ściągania" plików z takiego serwera za pośrednictwem gophera. Z problemem tym na szczęście radzą sobie przeglądarki WWW, które po zalogowaniu jawnie wymuszają przejście do katalogu głównego, w ich przypadku wystąpić może jednak inny problem - otóż niektóre z nich (np. starsze wersje NCSA Mosaic) korzystają z rzadko używanego tzw. trybu pasywnego protokołu ftp, którego serwer HellSoftu nie obsługuje. Korzystanie z zasobów serwera za pomocą takiej przeglądarki nie będzie więc możliwe (najpopularniejsza obecnie przeglądarka - Netscape - pracuje poprawnie; także najnowsza wersja NCSA Mosaic 2.0 "final beta" potrafi już współpracować z serwerami nie obsługującymi trybu pasywnego). Obu tych wad nie ma inny serwer ftp dostępny dla Netware - produkt firmy MurkWorks (zresztą bardzo podobny do serwera HellSoftu tak w oferowanych możliwościach, jak i sposobie konfiguracji), jest to jednakże program komercyjny. W Internecie dostępna jest co prawda jego wersja demonstracyjna, ale ma ona tak duże ograniczenia, że jej używanie nawet dla celu zapoznania się z programem jest praktycznie niemożliwe (firma MurkWorks oferuje natomiast możliwość uzyskania od niej bezpłatnie pliku-klucza, pozwalającego testować program bez ograniczeń przez 30 dni). Własny serwer ftp oferuje także sama firma Novell, w ramach pakietu Netware NFS, jego możliwości są jednakże skromniejsze w stosunku do obu produktów opisanych powyżej.

Oprócz serwera ftp następnym przydatnym programem w ofercie programistów z HellSoftu jest serwer BOOTP umożliwiający opisywany już centralny przydział adresów IP komputerom w sieci lokalnej. Jego ciekawostką w stosunku do klasycznych Unixowych serwerów BOOTP, posługujących się statycznie zdefiniowaną tablicą przypisującą odpowiednim hardware'owym adresom kart Ethernet - adresy IP, jest możliwość dynamicznego przydziału adresów z określonego zakresu numerów IP według kolejności otrzymywania żądań BOOTP z poszczególnych komputerów. W sytuacjach, gdy nie jest konieczne przypisanie konkretnych adresów do konkretnych komputerów, upraszcza to - w typowych serwerach BOOTP dosyć żmudną - procedurę tworzenia pliku konfiguracyjnego, eliminując konieczność wpisywania w nim numerów kart sieciowych wszystkich komputerów. Kolejnymi produktami Hellsoftu są serwery TFTP (raczej wątpliwej użyteczności w sieci Novell, gdyż protokół ten służy zasadniczo do uruchamiania bezdyskowych stacji Unixowych), fingera i gophera. Jeżeli chodzi o finger, program dostarczany przez HellSoft jest bardzo prymitywny - realizuje on jedynie najprostszą postać tej usługi, tzn. wypisanie listy użytkowników zalogowanych na serwerze w danej chwili, zupełnie nie obsługując bardzo pożytecznej formy polecenia "finger user@host". Dlatego lepiej sięgnąć po shareware'owy program o samoreklamującej się nazwie The Better Finger Daemon, napisany przez Jamesa Drewsa. Serwer gophera natomiast jest całkiem użyteczny, aczkolwiek jest to jeszcze wczesna wersja eksperymentalna (nosi numer 0.11) i realizuje zaledwie podstawowe opcje tego protokołu. Istnieje również serwer HTTP dla Netware, stworzony przez Great Lakes Area Commercial Internet (GLACI). Jest to produkt komercyjny, jednakże jego w pełni funkcjonalna (poza ograniczeniem czasowym) wersja demonstracyjna dostępna jest w Internecie do bezpłatnego testowania.

Na koniec wreszcie zostawiłem omówienie najatrakcyjniejszej usługi dostępnej dzięki włączeniu serwera Netware do Internetu, czyli poczty elektronicznej. Dostępny jest tutaj znakomity, bezpłatny system pocztowy o nazwie Pegasus Mail (w skrócie Pmail), którego autorem jest nowozelandczyk, David Harris. Pmail pozwala użytkownikom Novell Netware na wygodne, bezproblemowe wysyłanie i odbiór poczty Internetowej (a także lokalnej w obrębie sieci Novell) bezpośrednio ze swoich stanowisk roboczych. W przeciwieństwie do innych dostępnych systemów poczty elektronicznej dla Netware, Pegasus po zainstalowaniu nie wymaga żadnych dodatkowych czynności administracyjnych (np. odrębnego tworzenia kont pocztowych dla użytkowników, niezależnie od kont w Netware). Podobnie jak mailery w systemach Unixowych, dzięki swojemu silnemu zintegrowaniu z systemem "administruje się sam": automatycznie udostępnia wszystkim już istniejącym, jak również tworzonym później użytkownikom możliwość korzystania z pełnego zakresu poczty. Oczywiście w razie potrzeby możliwe jest np. ograniczenie dostępu do poczty dla pewnych użytkowników, jak chociażby standardowo tworzonego w typowej instalacji Netware konta "guest" - system jest bardzo elastycznie konfigurowalny. Pegasus Mail odczytuje wszelkie potrzebne informacje o użytkownikach bezpośrednio z bazy bindery systemu Netware, dlatego też zasadniczo przeznaczony jest tylko dla tych wersji Netware, w których baza owa istnieje, tzn. 3.12 lub niższej. W wersjach 4.x firma Novell zrezygnowała bowiem z bindery, tworząc w jej miejsce nowy sposób administrowania kontami użytkowników, zwany NDS (Netware Directory Services). Obecne wersje Pmaila nie obsługują NDS (wersja obsługująca NDS znajduje się w przygotowaniu), dlatego też praca z tym programem w Netware 4.x musi odbywać się w trybie emulacji bindery.

Pegasus Mail, podobnie jak inne programy poczty elektronicznej dla Netware, potrafi oczywiście współpracować ze standardowym Novellowskim systemem transportu poczty MHS (mocno okrojona wersja Pmaila, pracująca tylko z MHS, dołączana jest - pod nazwą FirstMail - do systemu Netware 3.12), jednakże MHS - stosunkowo trudny w konfigurowaniu - nie jest tu konieczny. Program potrafi sam dostarczać pocztę lokalną (w obrębie tego samego serwera lub innych serwerów w tej samej sieci Novell), natomiast do odbioru i wysyłania poczty Internetowej używa pracującego na serwerze Netware własnego modułu transportu SMTP o nazwie Mercury. Możliwa jest również współpraca z innym systemem transportu poczty o nazwie Charon, którego autorem jest Brad Clements. Charon nie pracuje na serwerze, lecz na dedykowanym komputerze w sieci Novell, pod kontrolą DOS, potrafi za to obsługiwać pocztę przesyłaną z/do wielu serwerów jednocześnie - także serwerów pracujących pod kontrolą starszych niż 3.xx wersji Netware, na których niemożliwe jest uruchomienie modułu Mercury. Dodatkowo, oprócz wysyłania i odbioru poczty, Charon działa jako serwer fingera, udostępniając listę użytkowników zalogowanych na wszystkich obsługiwanych przez niego serwerach. Niestety, Charon jest już programem dosyć starym i obecnie dalej nie rozwijanym. Zaletą z kolei Mercurego jest to, iż nie ma konieczności dedykowania dla jego potrzeb osobnego komputera, a także pełna współpraca z najnowszymi możliwościami Pmaila, obsługuje on jednakże użytkowników tylko tego serwera, na którym jest zainstalowany.

Trzeba zaznaczyć, iż program Pegasus Mail sam bezpośrednio nie nawiązuje żadnych połączeń w sieci Internet; działa on jako typowy user agent, odczytując pocztę z katalogu pocztowego użytkownika (SYS:MAIL\nnnn), natomiast pocztę przeznaczoną do wysłania wstawiając do zdefiniowanej na serwerze specjalnej kolejki pocztowej (definiuje się ją - w podobny sposób jak kolejki drukarkowe - przy instalacji Pegasusa). Zarówno wysyłaniem poczty znajdującej się w kolejce, jak i odbiorem poczty przychodzącej z Internetu i zapisywaniem jej do katalogu użytkownika zajmuje się system transportu poczty - Mercury lub Charon. Tak więc jeżeli jedyną usługą Internetową potrzebną w sieci Novell jest poczta, stanowiska robocze wcale nie muszą mieć dostępu do protokołu TCP/IP i aplikacji Internetowych; jedynym komputerem, który musi być widoczny w Internecie, jest komputer, na którym pracuje system transportu poczty (w przypadku zastosowania Charona nie musimy więc nawet instalować obsługi protokołu TCP/IP na serwerze). Zarówno Mercury, jak i Charon jako systemy transportu poczty mają pewną niedogodność - nie są mianowicie wyposażone w mechanizm rozwijania nazw domenowych (resolver), czyli zamiany ich na adresy IP z wykorzystaniem usług nameserwerów - nie potrafią wiec same przesyłać poczty bezpośrednio pod wskazany adres. Muszą one korzystać z pośrednictwa tzw. smart mailera, czyli jakiegokolwiek komputera wyposażonego w system transportu poczty potrafiący rozwijać nazwy domenowe - najczęściej wykorzystywane są w tym celu komputery Unixowe. Cała poczta wysyłana jest pod określony w konfiguracji adres smart mailera, a on dopiero przesyła ją dalej. Nie oznacza to jednakże, że chcąc korzystać z poczty elektronicznej w Netware musimy posiadać dodatkowo komputer Unixowy, gdyż w charakterze smart mailera można wykorzystać praktycznie dowolny taki komputer znajdujący się gdzieś blisko w Internecie i dostępny 24 godziny na dobę. W instytucjach posiadających scentralizowany serwer pocztowy (mail hub) obsługujący całą domenę on właśnie jest najlepszym kandydatem na smart mailer.

Pmail dostępny jest na trzech platformach: dla DOS, Windows i Macintosha, aczkolwiek tej ostatniej wersji autor poświęca najmniej uwagi i jest ona zawsze znacznie mniej dopracowana od pozostałych dwóch, a wszystkie nowe możliwości pojawiają się w niej ze znacznym opóźnieniem. W wersji DOS i Windows - wersji dla Macintosha nie miałem okazji testować ze względu na brak dostępu do tego typu sprzętu - wygodę pracy z programem i jego przyjazność dla użytkownika należy ocenić bardzo wysoko, przy czym wersja DOS-owa wydaje się nawet łatwiejsza i prostsza w użyciu niż wersja dla Windows, aczkolwiek ta druga niewątpliwie prezentuje się znacznie bardziej efektownie (rys.3). Program realizuje - i to bardzo dobrze - wszystkie standardowe funkcje, których możnaby oczekiwać od mailera, włącznie z takimi, jak automatyczny forward przychodzących listów na inny adres czy wysyłanie przygotowanego tekstu automatycznej odpowiedzi (w rodzaju np. "Jestem nieobecny, list zostanie przeczytany po dn. ..."). Moduł transportu poczty Mercury posiada nawet możliwości obsługi list dyskusyjnych, analogiczne do programów typu LISTSERV. Tak przychodzące, jak i wysyłane listy archiwizować można w drzewiastej (!) strukturze folderów, którymi można wygodnie manipulować - np. przenosić listy między nimi, czy przenosić same foldery w inne miejsce drzewa, a same foldery mają długie, opisowe nazwy. Nadejście każdego listu sygnalizowane jest typowym Novellowskim komunikatem (SEND) w 25 wierszu ekranu, zawierającym nadawcę i początkowy fragment tematu listu. Możliwe jest filtrowanie przychodzącej poczty według definiowalnych w szerokim zakresie kryteriów - można np. automatycznie kasować listy przychodzące z określonych adresów czy zawierające określony tekst w polu Subject:, a inne np. przenosić od razu do odpowiednich folderów. Bardzo łatwo realizuje się w programie Pegasus Mail wysyłanie dowolnych plików jako załączników do listów: pliki są automatycznie "w locie" kodowane i dekodowane w standardzie UUencode, BinHex (stosowany głównie przez programy pocztowe pracujące w środowisku Macintosha) lub MIME. Warto też wspomnieć o takim niezwykle użytecznym drobiazgu, jak możliwość wyboru przy redagowaniu odpowiedzi na list dowolnego adresu spośród pól "Reply-To:", "From:", "Sender:" oraz "To:" (ta ostatnia możliwość wbrew pozorom nie zawsze jest bez sensu!) jako adresu, na który ma zostać wysłana odpowiedź - przydaje się to szczególnie przy odpowiadaniu na listy pochodzące z list dyskusyjnych.

Pegasus Mail może też być używany z innymi niż Charon, Mercury i MHS systemami transportu poczty; dotyczy to także pracy w sieciach lokalnych innych niż Netware lub na komputerze "wolnostojącym" za pośrednictwem np. modemu. Potrzebne jest tylko napisanie odpowiednich programów sprzęgających Pmail z systemem transportu, tzw. user-defined gateways. Dostępne są takie gotowe programy dla UUCP (jako transport UUCP służy system Waffle), QWK (system transportu poczty stosowany głównie w BBS-ach i sieci Fido) oraz POP (Pmail w wersji dla Windows sam obsługuje protokół POP korzystając z WinSock'a, dla wersji DOS-owej istnieją dodatkowe programy). Pegasus Mail ma oczywiście - jak każdy program - pewne braki i niedoróbki, są one jednak bardzo niewielkie w porównaniu z jego zaletami i w niczym nie umniejszają bardzo wysokiej oceny tego programu jako jednego z najlepszych, jeżeli nie najlepszego systemu pocztowego dla Netware. Opinię tę potwierdza liczna i bardzo aktywna grupa użytkowników Pmaila na całym świecie, skupiona w liście dyskusyjnej PMAIL@UA1VM.UA.EDU. Warto jeszcze wspomnieć, że Pmail ma wręcz znakomity support ze strony autora, na poziomie niespotykanym nie tylko w przypadku produktów typu freeware, ale i niejednego programu komercyjnego. Pegasus może być użytkowany bezpłatnie, natomiast formę dobrowolnej zapłaty dla autora stanowi możliwość zakupienia drukowanych podręczników do programu.

Omawiając zagadnienie "Novell Netware a Internet" trzeba jeszcze odpowiedzieć na niezwykle często pojawiające się w tym kontekście pytanie. Pytanie to brzmi: Czy możliwy jest telnet do serwera Novell? Zadający to pytanie na ogół mają na myśli możliwość zdalnego zalogowania się w sieci Novell i pracy w sposób identyczny jak na komputerze bezpośrednio podłączonym do tej sieci. Skoro istnieją programy obsługujące serwer ftp, gophera, http, pocztę elektroniczną, to aż "prosi się", aby do pełnego zestawu usług dodać jeszcze jakieś oprogramowanie realizujące możliwość otwarcia sesji telnetowej i pracy na odległość, tak jak na maszynach Unixowych. Tymczasem jest to niemożliwe. Nie da się zrealizować takiej sesji na drodze czysto programowej, z bardzo prostej przyczyny: w przeciwieństwie do systemów typu Unix, gdzie programy wykonywane są przez procesor i w pamięci komputera, do którego się logujemy, w sieci Netware komputerem bezpośrednio wykonującym pracę obliczeniową jest - o czym nie należy zapominać - nasz konkretny, fizyczny PC włączony do tej sieci. Tak więc uruchomienie jakiegoś programu realizującego usługę telnetu na serwerze Netware dałoby co najwyżej możliwość zdalnego dostępu do konsoli serwera (coś w rodzaju Internetowego wariantu programu RCONSOLE) - i rzeczywiście, istnieją takie programy; ale aby móc pracować poprzez telnet tak jak na stanowisku roboczym w sieci - a na to głównie jest zapotrzebowanie - niezbędne jest... właśnie owo fizyczne stanowisko, dedykowany komputer, który będzie wykonywał nasze programy - i dopiero z tym komputerem, a nie z serwerem trzeba się łączyć poprzez telnet. Tu można zastosować dwa rozwiązania. Pierwszym będzie użycie zwykłego DOS-owego komputera - klienta Netware, na którym uruchomiony jest program telnetd (dostępny np. w archiwum Simtel pod adresem ftp://ftp.cyf-kr.edu.pl/pub/mirror/Simtel.Net/msdos/pktdrvr/telnetd.zip), umożliwiający zdalną pracę na PC za pośrednictwem telnetu. Oczywiście, z natury DOS-a tylko jeden użytkownik może połączyć się naraz (chyba, że mamy w sieci więcej takich komputerów z uruchomionym telnetd). Ze względu na to i na prymitywizm tego programu (kłopoty z przenoszeniem atrybutów ekranu - nie widać np. podświetleń w menu; skrajnie niewygodny sposób wprowadzania klawiszy sterujących itp.) nie jest to rozwiązanie godne polecenia. Lepszym, choć wymagającym zdecydowanie większego nakładu pracy sposobem jest włączenie do sieci Novell komputera z zainstalowanym systemem operacyjnym... Linux (darmowa wersja Unixa dla PC). Do komputera z Linuxem, jak do każdego Unixa, bez problemu można się "zatelnetować", zaś dzięki istnieniu w systemie Linux obsługi protokołu IPX oraz emulatora DOS-u można następnie otworzyć sobie sesję Netware (w podobny sposób można także wykorzystać system OS/2). Trzecie wreszcie, chyba najlepsze rozwiązanie, polega na zrezygnowaniu w ogóle z protokołu telnet: dla zdalnej pracy w sieci Novell wykorzystuje się zawartą w Netware możliwość tzw. tunelowania IP (IP tunnelling). Na serwerze, z którym chcemy się łączyć, musi pracować wchodzący standardowo w skład Netware moduł IPTUNNEL.NLM, "po drugiej stronie" zaś uruchamiamy zawarty w pakiecie LAN Workplace for DOS (trzeba niestety go kupić...) program IPTUNNEL.EXE. Nasz komputer zostaje wówczas włączony do sieci Netware na takich samych prawach, jak stacje przyłączone bezpośrednio; pakiety IPX są "zawijane" w pakiety IP i w ten sposób przebywają drogę poprzez Internet pomiędzy serwerem i naszym PC. Przy tym sposobie połączenia należy oczywiście pamiętać, aby kopie wszystkich najczęściej używanych programów, pliki tymczasowe itp. przechowywać na dysku lokalnym dla minimalizacji ruchu w sieci; każde odwołanie do pliku na dysku sieciowym Netware pociąga bowiem ze sobą transmisję przez Internet znacznych ilości danych. Jest to jednak niewątpliwie najlepszy sposób zdalnej pracy w sieci Novell.

Na zakończenie jak zwykle informacja o tym, gdzie można znaleźć w Internecie omawiane w tekście programy.
Sterownik ODIPKT rozpowszechniany jest w sieci pod adresem ftp://hsdndev.harvard.edu/pub/odipkt. W katalogu tym znajduje się wiele wersji (począwszy od najstarszej) tego sterownika - plik odipkt.com zawiera z reguły najaktualniejszą (bardziej szczegółowych informacji należy szukać w pliku README). Sterownik PDIPX znaleźć można w archiwum Simtel, jako plik ftp://ftp.cyf-kr.edu.pl/pub/mirror/Simtel.Net/msdos/pktdrvr/pdipx103.zip.
Oprogramowanie HellSoftu dostępne jest na serwerze novell.felk.cvut.cz (rzecz jasna, jest to serwer Novellowski obsługiwany przez własny produkt), w podkatalogu nw311. Znajduje się w nim seria dalszych podkatalogów (ftpd, bootpd, gopherd itp.) zawierających już konkretne pakiety. Należy zwrócić uwagę, że do działania serwerów ftp i gophera HellSoftu potrzebny jest moduł resolvera nazw domenowych, znajdujący się w podkatalogu resolv.
The Better Finger Daemon Jamesa Drewsa dostępny jest pod adresem ftp://ftp.cae.wisc.edu/pub/novell/nlm/fngrd202.zip (w chwili pisania tekstu aktualną wersją jest 2.02; numer ten, a co za tym idzie i nazwa pliku, może oczywiście ulec zmianie). Jest to program shareware, opłata licencyjna wynosi 35$ od jednego serwera lub 150$ za site license. Demonstracyjna wersja serwera ftp firmy MurkWorks znajduje się pod adresem ftp://ftp.msen.com/pub/vendor/murkworks/demos/ftpd, zaś serwera HTTP GLACI - ftp://ftp.glaci.com/pub/netware/.
Pegasus Mail rozpowszechniany jest przez dwa punkty dystrybucyjne: w USA - ftp://risc.ua.edu/pub/network/pegasus, a w Europie - ftp://ftp.let.rug.nl/pub/pmail. Aktualne wersje programu dla poszczególnych platform to pmail331.zip (DOS), winpm230.zip (Windows), pmmac212.hqx (Macintosh) oraz merc121.zip - system transportu poczty Mercury. Na tym samym serwerze, ale w podkatalogu /pub/charon, osiągalny jest również Charon.

Wszystkie wymienione powyżej programy (z wyjątkiem demonstracyjnych wersji serwerów MurkWorks i GLACI oraz Charona) znaleźć można również - zebrane razem - na serwerze ftp prowadzonym przez autora niniejszego tekstu, pod adresem inf.wsp.krakow.pl (pracuje tu również serwer HellSoftu), w podkatalogu novell/internet.

Powrót do wykazu artykułów o Internecie

Statystyka