Sadržaj


Osnovna stranica

Ciljevi

Izvedba

Korisnička dokumentacija

Odreknuće

Suradnici

Zahvale

Download

Kontakt


English 

 

Projekt: Softverski robot za daljinsko upravljanje

 

Puni naziv: "Daljinsko upravljanje procesom i praćenje mjerenja znanstvenog eksperimenta putem mobilne telefonije i-ili Interneta".
Projekt MZT broj 2002-007, br. ugovora: 353-01-10-2002.
Autor: Mario Stipčević, Institut Ruđer Bošković, Zagreb


Korisnička dokumentacija

Sadržaj

Što je SMS Robot ?

SMS Robot je softver čija je svrha omogu' iti korištenje putem SMS poruka, e-maila ili web-a druge softverske ili hardverske resurse koji nemaju tu mogućnost. Zamišljeno je da korisnik spomenutih resursa komunicira s Robotom putem dobro definirane sintakse koja ne ovisi o svrsi ili namjeni resursa. S druge strane, svaka hardverska ili softverska cjelina komunicira s Robotom također putem dobro definirane sintakse, a komunikacija se odvija uz posredovanje tzv. aplikacijskih modula.

Na primjer, razmatrajmo imeničku baza podataka kojoj želimo pristupiti putem SMS, e-maila ili web-a. U tu svrhu treba načiniti aplikacijski modul (program) koji zna pretražiti bazu po zadanim pojmovima. Taj modul treba razumijeti zahtjev kojeg prima od Robota i treba znati na koj način poslati svoj odgovor Robotu koji će ga proslijediti korisniku koji je poslao zahtjev.

Budući da Robot može "opsluživati" proizvoljan broj aplikacijskih modula, ideja komunikacije korisnika s Robotom je da treba navesti ime modula. Moduli razumiju neke naredbe, naredbe mogu imati parametre a paramentri mogu imati vrijednosti.

Na primjer, modul za pretragu imenika može se zvati "imenik", naredba za pretragu može biti "trazi", a parametri naredbe mogu biti "ime" i "zavod".

Prema tome bi kompletni zahtjev izgledao ovako:

imenik trazi ime="Pero"
ili
imenik trazi ime="Pero",zavod="Zavod za biologiju"

Nakon obrade zahtjeva, Robot će odgovor poslati na adresu (kanalom) s koje je stigao zahtjev. No moguće je specificirati i neku drugu povratnu adresu i-ili kanal. To činimo putem sistemskog modula reply. Taj modul je dio Robota i on je odgovoran za slanje odgovora. Sintaska je ista kao i za ostale module, a popis naredbi i njihovih parametara dan je u odjeljku Sistemski modul reply . Zahtjev koji uključuje specificiranje povratne adrese izgleda na primjer ovako:

imenik trazi ime="Pero",zavod="Zavod za biologiju" $ reply email address=mario@softhome.net

Uočimo da se zadaci za pojedine module odijeljuju znakom "$".

Na kraju riječ o sigurnosti. Prema do sad opisanom izgledalo bi da bilo koji korisnik može zadati bilo koju naredbu Robotu. No to nije tako. Da bi korisnik uspješno sproveo zahtjev moraju se steći dva uvjeta:

  • korisnik se je uspješno autenticirao robotu;
  • korisnik ima pravo izvršiti danu naredbu/naredbe za dani modul/module.

Ukoliko bilo što od toga nije ispunjeno KOMPLETNI ZAHTJEV SE ODBIJA.

Podržani operativni sustavi

Verzija 1.00 testirana je jedino pod Linuxom, distribucija Debian verzija 3.0r0-nonus stable. Program je najvećim dijelom posan u QB2C-u, a dobiveni C source je kompajliran s 2.95.4 20011002 kompajlerom koji je došao sa Debianom.

Ne očekujemo da bi bilo problema pri instalaciji SMS robota i na druge Linux distribucije iz tog doba (početak 2002.) ili mlađe, ukoliko su na raspolaganju svi nužni sistemski paketi koji nisu dio SMS robota (vidi Nužni paketi ).

Iako je sistem najpouzdaniji i najbolje testiran pod Linuxom ne vidimo prepreka za mogućnost instaliranja paketa pod MS Windows 98/Me/200NT/Xp koristeći CYGWIN. Napominjemo da nije potrebno instalirati podršku za X11.

Organizacija softverskih paketa

Instalacija softvera

Ukoliko želimo instalirati robota na neki "prazan" kompjuter, moramo učiniti s;lijedeće tri stvari u navedemonm redosljedu:
  • Instalirati operativni sustav;
  • instalirati nužno potrebne softverske pakete koji nisu dio SMS robota;
  • instalirati softverski paket SMS robota.
Sve potrebno, osim samog OS-a dolazi na CD-u SMS robota i može se downloadati s ove web stranice.

Instalacija OS-a

Instaliranje operativnog sustava (npr. Debian Linuxa) nije problematika koju obrađujemo u ovom uputstvu. Ukoliko se Robot želi instalirati pod MS Windowsima, nužno je prije samog Robota instalitati paket CYGWIN i u njega dodati pakete ekvivalentne nužno potrebnim softverskim paketima za Linux, pobrojanima u odjeljku Nužni paketi.

Nužni paketi

Nužni paketi za rad robota pod Debian Linuxom 3.0r0 su:

Naziv paketa Verzija Opis
mysql-server 3.23.49-8.2 mysql database server binaries
apache-ssl 1.3.26.1+1.48-0w Versatile high-performance HTTP server with SSL
php4 4.1.2-6 A server-side, HTML-embedded scripting language
php4-mysql 4.1.2-6 MySQL module for php4
csh 20020413-1 Shell with C-like syntax
sudo 1.6.6-1.1 Provides limited super user privileges to specific users

Te pakete treba instalirati prije instaliranja samog robota. Njih smo posebno istaknuli (i pridodali na naš instalacijski CD) budući da se oni obično ne instaliraju "po defaultu", nego ih treba doinstalirati zasebno. Osim samih paketa treba instalirati i sve pakete o kojima ovi ovise.

Dolje nevedeni programski paketi uglavnom dolaze "po defaultu", ali je svakako poželjno provjeriti jesu li instalirani i ispravno konfigurirani.

Za kompajliranje SMS robota nužna je neka (bilo koja) od inačica gcc C kompajlera. Precizna verzija gcc kompajlera nije bitna. Mi smo koristili gcc... koji je došao sa instalacijskim CD-ROMom Debiana.

Ukoliko Robotu želimo pristupati putem elektroničke pošte, treba mu omogućiti primanje e-maila, dakle instalirati programe za primanje i slanje e-maila.

Ukoliko želimo da Robot bude u stanju slati e-mail poruke (ovo je vrlo korisno čak i za komunikaciju prema GSM mobilnim telefonima), potrebno je instalirati BSD mail (naredba "Mail" odnosno "mail").

Kreiranje kompjuterskog računa (accounta) za Robota

Kao što je rečeno, SMS robot je virtualna osoba i njemu za rad treba normalan (nepovlašteni) korisnički račun. To se može najjednostavnije učiniti pomoću naredbe "adduser". Naša je preporuka da se robotu dodijeli korisnički račun sa zasebnom "grupom" koja ima isti naziva kao i korisničko ime, na primjer "bot". Kratkoća korisničkog imena kao i naziva stroja poželjna je radi toga što će se e-mail zahtjevi slati i s mobitela gdje je duljina SMS poruka ograničena.

Ukoliko Robotu namjeravamo pristupati putem elektroničke pošte, treba mu omogućiti primanje e-maila.

Instalacija SMS robota

Kad ste obavili sve nužne pripreme, tj. instalirali i konfigurirali OS i nužne pakete, možete pristupiti instaliranju samog robota, koji se nalazi u paketu smsbot-1.00.tgz . Detaljne upute nalaze se u datoteci INSTALL.txt koja je dio paketa. Ukratko, paket je potrebno "otpakirati", kompajlirati i pokrenuti konfiguracijski program Setup.

Bitno je razumijeti da paket sadrži dva dijela: sistemski i aplikacijski. Sistemski dio predstavlja samog Robota i njega čine baza, web sučelja (za administriranje i unos zahtjeva) te razni softverski moduli (masterbot, slave moduli i sistemski muduli) i razne druge sistemske datoteke ji se nalaze u u direktorijima ~/bin, ~/var, ~/pub i ~/public_html . Aplikacijski dio smješten je u cijelosti direktoriju ~/AppMod. U paketu dolazi jedan banalni primjer aplikacijskog modula na kojem su ilustrirane bitne funkcionalnosti aplik. modula: prijem i parsiranje zahtjeva, obrada zahtjeva, pisanje zapisnika ("log" datoteke) i slanje odgovora. Modul null vrlo je jednostavan: on prima zahtjev, parsira ga i vraća nazad pošiljatelju odnosno na adresu koja je specificirana u zahtjevu.

Konfiguriranje SMS robota

Konfiguracija se vrši program Setup.
(Eventualno, konfiguracija se može "podešavati" editiranjem datoteke .robotrc koja se nalazi u home direktoriju Robota.)

Instalacija hardvera

SMS robot sastoji se od softverskog i hardverskog dijela. U hardverski dio robota ubrajamo periferne jedinice koje omogućuju komunikaciju robota s korisnicima njegovih usluga, a to su: kompjuterska mreža (mrežna kartica ili modem) i SMS modul koji omogućuje slanje i primanje SMS poruka. Robot ne mora biti opremljen s oba tipa komunikacijske opreme, ali mora biti barem s jednim inače gubi svoj osnovni smisao daljinskog upravljanja i praćenja procesa.

Za komunikaciju putem SMS poruka koristili smo Siemensov GSM/GPRS modul MC35 spojen na serijski port (slika).

Vjerojatno je moguće u istu svrhu koristiti i razne druge GSM kompatibilne mobitele koji imaju priključak na serijski port, no u verziji 1.00 isprobali smo samo MC35.

Sav ostali hardver kojim Robot može upravljati ne smatramo dijelom robota i on je isključivo u kompetenciji administratora odnosno korisnika Robota.

Princip rada SMS robota

Robot se sastoji od masterbota, sistemskih modula (SysMod), robovskih modula (SlaveBot), aplikacijskih modula (AppMod), web sučelja za konfiguriranje robota, web sučelja za pristup robotu i baze (vidi shemu).

Ukratko, princip rada je ovaj. Korisnik šalje zahtjev preko slavebotova (putem SMS-a ili e-maila) ili preko web sučelja. Te zahtjeve prima masterbot koji ih rastavlja na komade od kojih se svaki odnosi na pojedini modul, provjerava autentičnost korisnika i njegova prava te autorizirane zahtjeve prosljeđuje odgovarajućim modulima. Postoji i jedan specijalni sistemski modul "scheduler" (raspoređivač) kojem se može zadati da šalje masterbotu zahtjeve prema nekom zadanom rasporedu (detalje o scheduleru vidi u odjeljku Scheduler ).

Slijedi detaljniji opis rada SMS robota.

  • masterbot prima od slavebota zahtjev u formi (vidi Sintaksa zahtjeva Robotu ):
    modul1 [modul1-cmdlist] [$ modul2 [modul2-cmdlist] ...] [* user pass]
    te putem opcija podatke o return-pathu:
    -email email | -sms broj | -web weburl
  • Ako nema polja s nazivom korisnika, masterbot dodaje user=guest, pass=""
  • Ako je dio s korisničkim podacima u skraćenom obliku, masterbot ga "normizira" na puni oblik:
    auth login u=korisnik,p=pass
  • masterbot predaje cijeli, tako normizirani zahtjev auth modulu na projveru autorizacije u autentikacije
  • Radi jednostavnosti, user se ne predstavlja svakom modulu zasebno, nego robotu. Jednom kad se user identificirao robotu, robot zna koja prava user ima na kojem modulu. Ispitivanje autentičnosti korisnika i njegovih prava (autorizaciju) provjerava sistemski modul auth.
  • auth iz normiziranog zahtjeva extrahira: user i pass te provjerava postojanje usera i njegovu autentičnost. Ako user ne postoji auth vraca kod -1. Ako user postoji, ali nema vise tanova auth vraca 2 itd. Postoje i drugi kodovi, ali oni nisu od interesa u ovom opisu. Ako je user autoriziran za sve zahtjeve (module i komande) onda i samo onda auth vraća masterbotu odgovor 0.
  • Ako je user autenticiran i autoriziran, masterbot traži da li postoji dio koji se odnosi na reply modul i ako ga ima taj cijeli komad pridodaje svakom parcijalnom dijelu koji ide pojedinim aplikacijskim modulima. Na primjer složeni zahtjev
    modul1 modul1-cmdlist $ modul2 modul2-cmdlist $ reply email a=user@home.net * user pass
    biti će prosljeđen modulima 1 i 2 ovako:
    modul1 modul1-cmdlist $ reply email a=user@home.net
    modul2 modul2-cmdlist $ reply email a=user@home.net
  • Aplikacijski moduli dalje sami nalaze odgovore i šalju ih kuda treba putem reply modula. Na aplikacijskom je modulu da formatizira output u linije jer reply modul ne formatizira nego šalje svaku liniju svojim SMS-om a cijelu poruku e-mailom ili web-om.

Upute za uporabu robota

Sintaksa zahtjeva robotu

Kao što je rečeno u uvodu, SMS robot se može shvatiti kao softver koji omogućuje SMS, e-mail i web pristup k softverskim paketima i-ili hardveru koji nemaju omogućen takav pristup. Pri tome je komunikacija između korisnika (spomenutih softverskih paketa odnosno hardvera) i robota preciznom sintaksom koja može udovoljiti vrlo širokom spektru namjena. Poveznica između robota i softverskih paketa i-ili hardvera su aplikacijski moduli.

Ideja je jednostavna: svaki modul ima skup naredbi (cmd) koje razumije, svaka naredba može imati parametre (par), a parametri mogu imati vrijednosti (val). Naredbe su odijeljene znakom ";", a parametri unutar naredbe znakom ",". Zahtjev za jedan modul izgleda ovako:

modul cmd1 [par1[=val1][,par2=[val2]]...][; cmd2 [par1[=val1][,par2=[val2]]...]...]

U jednom zahtjevu možemo odjednom komunicirati s više modula, a svakom modulu možemo zadati više naredbi. Moduli su medjusobno odvojeni znakom "$".
Konačno, sintaksa naj općenitijeg zahtjeva izgleda ovako:

modul1 modul1-cmdlist [$ modul2 modul2-cmdlist [$ modul3 modul3-cmdlist] ...]

gdje je modul-cmdlist:
cmd [parlist][; cmd [parlist]...]

gdje je parlist:
par[=value][,par[=value]...]

Administracija SMS robota

Svi podaci o raspoloživim aplikacijskim i sistemskim modulima interesantnim za korisnike, zatim podaci o korisnicima i njihovim pravima sadržani su u Robotovoj bazi podataka. Baza je načinjena u MySQL-u. Administriranje Robota svodi se na unos i-ili izmjenu podataka u toj bazi, a moguće je samo putem administratorskog Web sučelja.
U ovom odjeljku opisujemo administratorsko Web sučelje i način rada s njime. Sučelje se može podijeliti na dvije cjeline:
  • dio za unos podataka o korisnicima i
  • dio sa unos podataka o aktivnim aplikacijskim modulima.

Pristup administratorskom sučelju zaštićen je lozinkom, a pristup samoj web stranici moguće jedino putem "sigurnog" HTTPS protokola.
Slika 1.

Konfiguriranje korisničkog imena i lozinke administratora robota može se izvršiti putem konfiguracijskog programa "Setup" ili "ručno". Taj je postupak opisan u odjeljku Konfiguriranje SMS robota .

Dodavanje korisnika

Nakon unosa korisničkog imena i lozinke otvara se stranica za kreiranje korisnika, zapravo glavna stranica tzv. "konfiguracijske konzole", koja izgleda ovako:
Slika 2.

Tu imamo više mogućnosti:

  • klikom na "ADD NEW" možemo dodati (kreirati) novog korisnika,
  • klikom na "EDIT" možemo unijeti izmjene u osobnim podacima dotičnog korisnika,
  • klikom na "DELETE" možemo obrisati/ukloniti dotičnog korisnika, te konačno
  • klikom na "Application modules management" možemo otići na glavnu stranicu za kreiranje opisa aplikacijskih modula.
Prve dvije mogućnosti vode na stranicu pojedinačnog korisnika koja izgleda slično ovom primjeru:
Slika 3.

Značenje pojedinih polja je prilično intuitivno.

Prvo polje je korisničko ime korisnika - ono mora biti jedinstveno pri čemu se velika slova razlkuju od malih, npr. "Mario" i "mario" nisu identična korisnička imena.

Slijede polja za ime i prezime korisnika.

Tajna (secret) je za niz alfanumeričkih znakova (trenutno 40 slovčanih znakova) koji predstavljaju tajni individualni ključ korisnika. Tajni niz generira se i unosi u bazu automatski prilikom dodavanja novog korisnika. Interpretacija tajnog niza ovisi o tome da li se za autentikaciju koriste jednokratne lozinke (tzv. TAN-ovi) ili token. Ono što je bitno napomenuti jest da se tajni niz nalazi samo u bazi i nigdje drugdje. Postupak autentikcije korisnika je takav da se taj ključ treba jedino nalaziti u bazi Robota.

U polje "Expires" unosi se datum nakon kojeg automatski presatve vrijediti korisnički račun. U verziji 1.00 unešeni se datum ignorira.

Kad korisnik pošalje neki zahtjev Robotu, rezultati obrade zahtjeva (ako ih ima) šalju se nazad korisniku koji je poslao zahtjev. Slijedeća dva polja sadrže podathe o SMS i e-mail adresama putem kojih korisnik želi primiti povratnu informaciju u slučaju da nije drugačije zadano u samom zahtjevu ili da se koristi skraćeni format povratne adrese (vidi odjeljak o sistemskom modulu reply).

Jedna od gore navedenih adresa može se izabrati kao "defaultna" (polje Default). Ona se koristi u slučaju da je zahtjev došao od poznatog korisnika (navedenog u bazi) te da u zahtjevu nema odjeljka koji se odnosi na modul reply.

Završno polje sadrži informaciju o tome koristi li korisnik za autentikaciju sistem unaprijed izračunatih jednokratnih lozinki (TAN-ova) ili sistem dinamičkih jednokratnih lozinki za čiju je proizvodnju potreban specijalni uređaj, takozvani token. U verziji 1.00 ovo se polje ignorira i jedini mogući način autentikacije je putem liste TAN-ova.

Dvije tipke dolje desno na slici 3 odnose se na TAN-ove. Klikom na tipku "Generiraj TAN" pokreće se generiranje liste od 100 TAN-ova za korisnika. Tipičan rezultat takve akcije prikazan je na slici 3a.
Slika 3a.

TAN-ovi se moraju koristiti prema rastućem rednom broju, od 0 do 99. Kad su svi TAN-ovi iz jedne tablice iscrpljeni, počinju vrijediti TAN-ovi iz iduće. Ako korisnik izgubi listu TAN-ova ili izgubi redosljed, treba resetirati listu TAN-ova (tipka "Resetiraj TAN-ove") čime odmah prestaju vrijediti svi do tada generirani TAN-ovi, bez obzira na to da li su iskorišteni ili nisu.

Administracija modula

Kao što je rečeno u uvodu, Robot sam po sebi ne može vršiti nikakav koristan zadatak. Korisne zadaće obavljaju tzv. aplikacijski moduli (vidi odjeljak Aplikacijski moduli). To su u stvari programi koji primaju zadatke od Robota (preciznije "masterbota") i koji znaju pisane rezultate predati Robotu (točnije sistemskom modulu "reply").

Kada se u robota doda novi aplikacijski modul (vidi odjeljak Aplikacijski moduli) potrebno je u bazu unijeti neke osnovne podatke o modulu. Bez toga, robot ne bi mogao koristiti spomenuti modul, niti bi ovaj bio vidljiv u korisničkom sučelju. Slika 4 prikazuje formular za unos osnovnih podataka o modulu: njegov naziv (stvarna ekzekutabla mora imati ime naziv-AppMod), kratki opis koji ima svrhu da administratora podsjeti čemu modul služi i polje koje označava na koji način masterbot treba prenijeti zahtjev modulu. Postoje čak četiri mogućnosti čija sloboda izbora olakšava pisanje modula (vidi odjeljak Aplikacijski moduli).
Slika 4. Unos podataka o modulu

Klikom na dugme "Unos" otvara se novi formular (slika 5) putem kojeg treba unijeti popis naredbi koje razumije spomenuti modul. Naredbe se dodaju jedna po jedna. Modul mora biti u stanju razumijeti odnosno primiti barem jednu naredbu, inače će ga biti nemoguće doseći putem zahtjeva odnosno putem SMS robota. Na primjer, modul "imenik" može biti engine za pretragu baze zaposlenika Instituta Ruđer Bošković, pri čemu naredba za pretragu može imati naziv "search".

Da bismo dodali naredbu, potrebno se je vratiti korak unazad klikom na link "Application modules managenent". Time ćemo se vratiti na tablicu svih modula (koji su popisani u bazi). Tipična tablica prikazana je na slici 5.
Slika 5. Tablica modula

Klikom na link "CMD" otvaramo formular za unos naredbi za dotični modul (slika 6.)
Slika 6. Dodavanje novih komandi

Klikom na tipku "Unos" vršimo unos podataka u bazu i vraćamo se na tablicu modula (slika 6). Iteracijom može se unijeti proizvoljan broj naredbi za dani modul. Klikom na tipku "Odustani" vraćamo se na tablicu modula, pri čemu nema promjena u bazi.

Popis naredbi koje su unešene za pojedini modul možemo dobiti tako da u tablici modula (slika 6) kliknemo na polje "EDIT" za odgovarajući modul. Na tom formularu možemo izvršiti unos parametara za sva
Slika 7. Tablica naredbi

U ovom primjeru vidimo da je upisana naredba "search" čija je namjena pretraga imenika po ključnim riječima. Klikom na polje "PARAMETERS" mogu se dodavati parametri za dotičnu naredbu.

Sintaksa zahtjeva koji se šalju SMS robotu (opisana u odjeljku Sintaksa zahtjeva ) omogućuje da svaka naredba ima nijedan ili više parametara te da svaki parametar može (ali i ne mora) imati sposobnost poprimanja neke vrijednosti. Klikom na polje "PARAMETERS" u gornjem formularu, otvoriti će se formular za unos parametara (slika 8).
Slika 8. Dodavanje parametara

U ovom smo primjeru pokazali dodavanje modula "imenik", naredbe "search" i njenog parametra "pattern" koji poprima vrijednost. Na primjer, zahtjev SMS robotu kojim se žele dobiti imenički podaci za osobu "Marko Marković" glasio bi ovako:

imenik search pattern="Marko Marković"

Korisnička prava

Ovdje je bitno napomenuti da se za svakog korisnika mora definirati ima li ili nema pravo izvršavati određene komande. Prema defaultu nijedan korisnik nema prava izvršiti ni jednu komandu. Da bi se to promijenilo treba korisnicima dati prava putem formulara opisanog na slici 5.

Klikom na polje "RIGHTS" otvara se formular (slika 9) na kojem se svakom korisniku može dodijeliti ili uskratiti pravo na izvršavanje dotične komande.
Slika 9. Uređivanje korisničkih prava

Pristup Robotu putem SMS poruka

Pristup Robotu putem elektroničke pošte

Korisničko Web sučelje

Još jedan način komunikacije s Robotom je putem korisniku prijateljskog Web sučelja koje se može vizualizirati putem bilo kojeg Web preglednika, uključivo i one sa samo tekstialnim prikazom kao što je Lynx. Ovaj način komunikacije će najvjerojatnije biti preferiran ukoliko je na raspolaganju stalan pristup Internetu. Slijede upute za korištenje tog sučelja.

Na prvoj stranici (slika 1.) korisnik upisuje svoje korisničko ime i tan. Tan je niz od četiri slova i služi za autentifikaciju korisnika. Za svako prijavljivanje za rad na sustavu koristi se drugi tan. Korisnik zato unaprijed dobije popis od 100 tanova te nakon svakog korištenja prekriži potrošeni tan.
Slika 1.

Pri dnu stranice je izbornik za upravljanje sustavom. Ako je natpis upisan bijelom bojom onda taj tekst označava trenutno otvoreni prozor. Tako je na slici 1. označena tipka s natpisom Korisnik što znači da se na toj stranici korisnik autentificira. Ako tipka ima podebljani rub, onda se na nju može kliknuti i otići na odgovarajuću stranicu. Na slici 1. su tako označene tipke s natpisima:
Zahtjev za odlazak na stranicu za izradu zahtjeva pomoću izbornika i
Utipkaj zahtjev za odlazak na stranice za ručno upisivanje zahtjeva
Klikanjem na tipke koje su označene s tankim rubom ne će se dogoditi ništa. Takav primjer je tipka s natpisom Pošalji koja inače služi za slanje zahtjeva. Kako se na prvoj stranici korisnici samo autentificiraju i kako još nije napravljen zahtjev, onda se on ne može ni poslati. Na svakoj stranici se nalazi i tipka s natpisom Izlaz. Ona služi za brisanje cijelog zahtjeva i prekid rada sa sustavom. Ona vraća korisnika na početnu stranicu.

Pritiskom na tipku Zahtjev odlazi se na stranicu na kojoj se radi zahtjev SMS-robotu. Slika 2. prikazuje tu stranicu s primjerom zahtjeva. Unutar crnog okvira se u padajućem izborniku odabire modul kojemu se treba poslati neka naredba. U tom padajućem izborniku se nalaze samo oni moduli s naredbama za koje korisnik ima pravo pokretanja. Kada korisnik odabere modul, u plavom okviru u padajućem izborniku odabire naredbu koju želi izvršiti.
Slika 2.

Ako ta naredba ima parametre, korisnik može i njih odabrati u sivom okviru. Odabere li parametar koji može imati neku vrijednost, uključuje mu se tekstni okvir za upis te vrijednosti. Pritiskom na tipku Dodaj parametar, taj parametar se sprema u popis parametara za tu naredbu. To je nužno zato što jedna naredba može imati više parametara. Korisnik može dodati naredbu i njezine parametre u popis naredbi pritiskom na tipku Dodaj naredbu. Isto tako može dodati i cijeli modul s odabranim naredbama i njihovim parametrima u popis modula pritiskom na tipku Dodaj modul. Sa svakog popisa se može i ukloniti zapis. To se radi tako da se označi zapis ili više zapisa i pritisne se odgovarajuća tipka za brisanje (Izbriši parametar, Izbriši naredbu ili Izbriši modul). Kada se u popis doda modul, onda se pri dnu stranice ispiše cijeli zahtjev SMS-robotu s ispravnom sintaksom. Riječi u sintaksi su označene različitom bojom tako da ih je lakše razlikovati. Tako su moduli označeni crnom, naredbe plavom, a parametri sivom, sve u skladu s okvirima u kojima se zadaju. Crvenom bojom je označen znak za odvajanje modulâ u zahtjevu ($), znak za odvajanje naredbi jednog modula (;) i znak za odvajanje korisničkog imena od ostatka zahtjeva (*). Korisničko ime je označeno tamno plavom bojom.

Kada se u popisu modula nađe neki modul s naredbom (dakle određen je zahtjev), tipka Pošalji se uključuje. Pritiskom na tu tipku zahtjev se šalje SMS-robotu. Nakon što je zahtjev uspješno poslan, otvara se stranica koja korisnika obavještava o tome (slika 3.).
Slika 3.

Nakon toga se može napraviti novi zahtjev SMS-robotu pritiskom na tipku Novi zahtjev te se opet otvara stranica za izradu zahtjeva (slika 2.).

Ako se na prvoj stranici pritisne tipka Utipkaj zahtjev ili na stranici na kojoj se korisnik obavještava da je zahtjev poslan SMS-robotu pritisne tipka Utipkaj novi zahtjev, otvara se stranica za ručni upis zahtjeva (slika 4.). Na toj stranici korisnik može u tekstni okvir utipkati zahtjev. Korisnik ne mora na karaju zahtjeva upisati svoje korisničko ime jer se ono automatski dodaje pošto sustav zna tko je korisnik koji upisuje zahtjev.
Slika 4.

Pritiskom na tipku Pošalji otvara se stranica na kojoj korisnik može još jednom prevjeriti svoj zahtjev (slika 5.) pa ako ga je dobro upisao treba još jednom pritisnuti tipku Pošalji.
Slika 5.

Tada se otvara stranica na kojoj se korisnika obavještava da je zahtjev poslan SMS-robotu. Na toj stranici riječi u zahtjevu nisu sintaksno obojene (slika 6.) zato što sustav nema ugrađeni parser koji bi provjeravao sintaksu ručno upisanog zahtjeva.
Slika 6.

Razno

Sistem autentikacije korisnika putem liste TAN-ova

SMS robot koristi slijedeći sistem autorizacije TAN-ovima. SISTEM AUTORIZACIJE TAN-OVIMA

TAN-ovi su 4 slovčani i generiraju se na slučajan način između njih 26^4=457000. Generira se batch od 100 TAN-ova i zajedno s njim slučajni 40-slovčani tajni ključ skey korisnika i tablica sjena. Za svaki TAN postoji jedna sjena koja se računa ovako: sha(i)=Hash8(skey|TAN(i)), gdje je Hash neka univerzalna hash funkcija koja hashira bilo kaj u 8 slova (npr. srezani MD5), a znak | označava konkatenaciju nizova.

TAN-ovi i ključ se koriste jednom. Nakon toga generiraju se novi TAN-ovi i novi tajni ključ.

Tajni ključ korisnika i sjene poznati su samo Robotu, a TAN-ovi samo korisniku.

User se autenticira tako da se predstavi svojim korisničkim imenom (koje je javno i nepromjenjivo) koje ga povezuje s trenutnim tajnim nizom i jednim TAN brojem. Autentičnost se provjerava tako da se izračuna Hash8(skey|TAN) i usporedi sa sjenom koja je trenutno na redu. Nakon svake uspješne autentikacije korisnik odbacuje ispkorišteni TAN a Robot odbacuje iskorištenu sjenu ili pomiče pointer na slijedeću. Za slijedeću autentikaciju se koristi slijedeći TAN u nizu.

Ako je autentikacija neuspješna korisnik ima ukupno N pokušaja nakon čega mu se račun blokira te mora kontaktirati administratora.

DISKUSIJA METODE

Sjena je duga 8 slova a TAN 4. Sjena je uzeta dulja radi toga da bi vjerojatnost da dva različita TAN-a imaju istu sjenu bila mala kako se ne bi povećala osjetljivost na napad pogađanja TAN-a.

Ta vjerojatnost (uz zadržavanje relativno malog batcha) mogla bi ostati zanemarljivo mala i u slučaju kada bi sjena bila kraća od TAN-a (što bi bilo povoljno ze neke tipove napada) ako bi i TAN i sjena bili dugi. No radi praktičnih razloga želimo kratke TAN-ove.

ANALIZA SIGURNOSTI

NAPAD 1 Pretpostavka. Napadač generira slučajni TAN. Postoji vjerojatnost N/457000 da se uspješno autenticira. Uspjeh slijedećeg napada je jednak (ne povećava se) bez obzira na ishod prvog napada. (Za superkorisnika (administratora) mogu se zahtijevati 2 uzastopna TAN-a iz M pokušaja pri čemu je vjerojatnost uspješnog napada M/2E11. Ta mogućnost međutim nije implementirana u verziji 1.00.)

NAPAD 2 Pretpostavka. Napadač zna redni broj "i" slijedećeg TAN-a u nizu i zna njegovu sjenu sha(i). Napadač bi morao invertirati funkciju Hash(8) što je nemoguće jer sa samo 8 izlaznih slova nije moguće jednoznačno odrediti 48 ulaznih slova, odnosno trebalo bi pogađati 26^(48-8)=4E56 kombinacija.

NAPAD 3 Pretpostavka. Napadač zna redni broj "i" slijedećeg TAN-a u nizu, zna njegovu sjenu sha(i) i zna tajni ključ korisnika.

Napadač bi morao invertirati funkciju Hash(8) što je moguće učiniti jednoznačno s velikom vjerojatnošću budući da je sjena dosta dulja od TAN-a. Mala je dakle vjerojatnost da postoje dva TAN-a koji daju istu sjenu. Problem je međutim što se funkcija Hash8 ne da invertirati brže nego da se pogađa njen ulaz pa je to dakle zadatak reda isprobavanja svih TAN-ova ili 26^4=457000. To je relativno mali zadatak no da bi se došlo dotle potrebno je razvaliti i bazu i doći u posjed datoteke sa sjenama. Posao kojeg napadač ima cak i u tom za njega vrlo povoljnom slučaju raste eksponencijalno s duljinom TAN brojeva, pa bi se odabirom nesto duljih tanova i tu dao napadaču zagorčati život samo je pitanje ima li to smisla kad je vec očigledno ušao na sistem.

Općenito, kad bi sjena duljine s bila kraća od TAN-a duljine t zadatak bi bio pogađanje reda približno 26^(s+t). Npr. kad bi TAN bio duljine 8, a sjena duljine 4, zadatak napada 3 bi bio solidnih 10^17 (?).

Aplikacijski moduli

ŠTO JE APPMOD (APLIKACIJSKI MODUL)

Aplikacijski modul je programski paket koji omogućuje izvršavanje nekog zadatka putem SMS robota. Robot aplikacijskom modulu osigurava dolaznu i odlaznu komunikacijsku infrastrukturu (koja osigurava kripto sigurnost, management korisnika itd), no aplikacijski modul je zadužen za izvršavanje specifičnog zadatka. Robot bez aplikacijskih modula ne baš i ne može učiniti neku korisnu akciju.

Robot može "opsluživati" neograničen broj aplikacijskih modula.

Kao primjer aplikacijskog modula možemo zamisliti "imenik". Bitni dio tog modula je egzekutabla koja može primiti (od Robota) neki zahtjev, na primjer, "telefonski broj Pere Perića" procesirati ga i odgovor poslati Robotu. Robot se brine o primanju zahtjeva, autentikaciji korisnika koji je poslao zahtjev, njegovom autoriziranju, formatiranju u standardni format i isporuičivanju odgovarajućem aplikacijskom modulu (u ovom slučaju imeniku) te o slanju odgovora na traženu povratnu adresu/kanal.

OSNOVNI POJMOVI

SMS robot sastoji se od većeg broja jedinica (vidi odjeljak o organizaciji SMS robota). Za funkcioniranje aplikacijskig modula (appmod) važni su samo ovi sistemski moduli i sistemske egzekutable:

  • masterbot
  • reply-SysMod
  • parser
  • newreq.
Robotov home direktorij sadrži oveći broj direktorija od kojih su neki značajni za spomenuti ovdje, to su:
${BOT} = username robota (npr. bot)
${HOME} = home direktorij SMS robota (obicno ~${BOT}, npr. /home/bot/)
${APPMOD} = vršni direktorij za appmodule (obično ${HOME}/AppMod/)
${APPBIN} = direktorij za aplikac. egzekutable (obično ${HOME}/AppMod/bin/)
${BOTBIN} = direktorij s sistemskim modulima (obično ${HOME}/bin/)
${BOTPUB} = direktorij s "javnim" egzekutablama (obično ${HOME}/pub/)

Aplikacijski modul "živi" u ${APPMOD} i smije pisati isključivo u potprostor tog direktorija. Pisanje u /tmp zabranjeno je iz sigurnosnih razloga.

Kad Robot zaprimi zahtjev on ga procesira (autentikacija, autorizacija, formatiranje...) te na kraju masterbot predaje zahtjev odgovarajućem appmodu. Komunikacija između masterbota i appmoda je jednosmjerna i ide samo u smjeru masterbot -> aplikacijski modul. Proslijeđeni zahtjev stiže u jednoj liniji i punom normalnom formatu:

modul modul-cmdlist $ reply (e)mail|(s)ms (a)ddress=x|user=x

gdje su:

modul-cmdlist:
cmd [parlist][; cmd [parlist]...]
parlist:
par[=value][,par[=value]...]

Za parsiranje zahtjeva appmod može koristiti vlastitu rutinu, rutinu u QB2C-u ili C-u koja dolazi s robotskim paketom (ParseModuleForCommandsAndTheirParlists(.c)(.bas)) ili sistemsku egzekutablu parser koja parsira zahtjev i izbacuje ga na stdout. Sintaksa parsera je:

${BOTPUB}/parser [-debug] < requestfile > replyfile

ili:

echo '...zahtjev...' | ${BOTPUB}/parser

pri čemu parser izbacuje parsirani zahtjev na stdout. (Detaljnije o parseru vidi u odjeljku Parser .) Nakon što appmod obavi svoje, on može predati odgovor sistemskom modulu koji se zove reply-SysMod. Odgovor mora imati striktnu robotsku sintaksu (vidi Sintaksa zahtjeva Robotu ):

${BOTBIN}/reply-SysMod -replyinfo replyinfo < odgovor-file

ili:

echo '...odgovor...' ${BOTBIN}/reply-SysMod -replyinfo replyinfo

gdje replyinfo mora biti puna sintaksa za reply modul:

reply (e)mail|(s)ms|(w)eb|default (a)ddress=x|(u)ser=y[,(l)pm=1]

Primjeri:

reply email user=john
reply email a=john@softhome.net
reply sms a=098867805
reply default user=john

(Detalje vidi u opisu reply-SysModa .)

Pisanje aplikacijskih modula

Prije nego se krene na pisanje aplikacijskog modula (appmoda) potrebno se je odlučiti za jedan od 4 podržana načina komunikacije između masterbota i appmoda.

Mogući su slijedeći "tipovi" komunikacije:
1. preko fifa;
2. preko datoteka koje masterbot ostavlja na nekom mjestu a appmod ih uzima, čita i briše;
3. na način da masterbot izvrši modul i preda mu zahtjev preko stdin-a;
4. tako da modul izvršava naredbu newreq i putem stdouta dobiva traženi zahtjev.

Detalje o svakom od načina komunikacije vidi u odjeljku TIPOVI KOMUNIKACIJE.

Za modul imena "mymodule" treba u direktoriju ${APPBIN} postojati egzekutabla imena "mymodule-AppMod" (može biti symlink).

Vlasnik ekzekutable treba biti ${BOT} i on mora imati rwx ovlaštenja.

INICIJALIZACIJSKE DATOTEKE

Modul kod pokretanja može čitati nekakve datoteke kojima se konfigurira bez rekompajliranja. Primjer ~${BOT}/.mymodulerc. Takve datoteke smjestiti u direktorij ${APPMOD}/conf/ . One u pravilu trebaju pocinjati znakom "." i zavrsavati slogom "rc", iako je to samo obicaj.

Logovi neka se pišu u direktorij ${APPMOD}/log/ i nek imaju ime koje podsjeća na ime modula, npr mymodule.log . Za sada, format log datoteke je autoru modula na volju.

STARTUP APP-DAEMONA

Prvo pokretanje aplikacijskih modula koji su daemoni za sada nije rijeseno. Za sada se pokrecu rucno (npr: mymodule-AppMod 2>&1 /dev/null &).

JEDAN PRIMJER APPMODA (tip 3)

Kod tipa 3, masterbot izvrsava modul (tj. egzekutablu ${APPMOD}/bin/mymodule-AppMod) jednom i pri tome joj predaje zahtjev putem standardnog ulaza. Dolje opisani modul je vrlo jednostavan: on primljenu naredbu samo prosljedjuje primatelju konstantne e-mail adrese.

#!/bin/csh
echo | mail -s "$<" Pero.Peric@irb.hr

Datoteku koja sadrzi gornje dvije linije nazvati npr. "mymodule" i staviti u direktorij ${APPMOD}/bin .

JOŠ JEDAN PRIMJER APPMODA (tip 2)

.....

TIPOVI KOMUNIKACIJE MASTERBOT -> APPMOD

Postoji 5 načina na koje masterbot može predati zahtjev nekom appmodu (samo su 4 netrivijalna). Da bi masterbot znao koji tip valja upotrijebiti za koji appmod, taj podatak (broj "tipa" komunikacije) treba unijeti u robotovu bazu podataka putem administratorskog sučelja kako je opisano u odjeljku Administracija modula . Pretpostavimo da se appmod zove "mymodule", te da smo vršni direktorij za aplikacijskke module označili s ${APPMOD}. U tom slučaju aplikacijski modul (egzekutbla) nosi puni naziv ${APPMOD}/bin/mymodule-AppMod. Nadalje označimo direktorij sa javnim egzekutablama s ${BOTPUB}/bin/. Tipovi komunikacije su slijedeći:

  • TIP 0
    Nema nikakva prijenosa prema appmodu.
  • TIP 1
    masterbot upisuje zahtjev u fifo datoteku ciji je puni naziv: ${APPMOD}/fifo/mymodule.fifo Fifo "datoteka" se može kreirati ovako: mkfifo ${APPMOD}/AppMod/fifo/mymodule.fifo U tom slucaju appmod "mymodule" mora biti daemon: on živi cijelo vrijeme i čeka da mu preko fifo-a stigne zahtjev. U trenutku kad masterbot "ubaci" u fifo neki zahtjev u obliku JEDNE LINIJE appmodul treba obaviti nažnacene operacije koje ta linija podrazumijeva. Kad je obavio traženo i eventualno poslao odgovor putem reply-SysMod-a, vraća se na čitanje fifa. Program je dakle u beskonačnoj petlji, odnosno radi kao daemon.
  • TIP 2
    masterbot upisuje zahtjev u jednokratnu datoteku punog naziva: ${APPMOD}/reqst/mymodule-*.XXXXXX gdje * označava neki alfanumerički znak koji abecedno raste u vremenu, a "XXXXXX" slučajni, jednokratni alfanumerički niz. U tom slučaju appmod sam bira trenutak kada će čitati zahtjeve koji su pristigli na njegovo ime, a on sam može i ne mora biti daemon. Jednom kada je datoteka sa zahtjevom procitana, appmod ju MORA obrisati.
  • TIP 3
    masterbot izvršava modul (tj egzekutablu ${APPMOD}/bin/mymodule-AppMod) jednom i pri tome joj predaje zahtjev putem standardnog ulaza. Ono što se pri tom događa ekvivalentno je izvršavanju naredbe:
    echo "...zahtjev...." | ${APPMOD}/bin/mymodule-AppMod 2>&1 > /dev/null &
    U ovom slučaju očito appmod NE MOŽE biti daemon.
  • TIP 4
    U ovom načinu masterbot ostavlja zahtjeve za appmod na nekom mjestu, a appmod do zahtjeva dolazi posredno, putem naredbe newreq. Na primjer appmod imena "mymodule" može na slijedeći nacin provjeriti ima li u trenutku kakvih zahtjeva za njega: ${SYSBIN}/newreq -modul mymodule pri čemu će tekst zahtjeva (neparsirani) biti izbačen na stdout. Ovaj način je sličan načinu 2 čime je omogućeno da appmod bude daemon, ali je primanje zahtjeva u tehničkom dijelu prepušteno sistemu i time pojednostavljeno.

Sistemski moduli

masterbot

Sistemski modul reply

Scheduler

Scheduler je sistemski dio robota (točnije sistemski modul) koji omogu' uje stvaranje rasporeda izvršavanja zahtjeva. Putem schedulera korisnik može zadati da se neki zahtjev ili zahtjevi izvrše po nekom unaprijed određenom preciznom vremenskom rasporedu.

Prvo trebamo definirati neke pojmove. U jednom zahtjevu SMS robotu može biti sadržano više jednostavnih "zadataka". Na primjer u zahtjevu:

ng report $ imenik search pattern=pero * mario

sadržana su dva zadatka: od modula ng se zahtijeva report, a od modula imenik se zahtijevaju imenički podaci o svim osobama čije je ime Pero. Kao što ' emo vidjeti kasnije, scheduler je također modul (naziva sched) kojem se mogu slati zahtjevi koji su vrlo jednostavni u zapisu ali se sastoje od mnoštva zadataka.

Za sada, u verziji 1.00, postoji samo ljuska schedulera s minimalnom (ali ipak u velikom postotku slučajeva dovoljnom) operativnošću odnosno podržanom sintaksom. Predviđa se da bi se u kasnijim verzijama SMS robota sintaksa proširila.

Osnovna strategija rada schedulera treba dati (i u verziji 1.00 već daje) odgovore na slijedeća pitanja:

  • kome i kako masterbot prosljeđuje zahtjeve;
  • na koji je način ostvarena sigurnost (autentikacija i autorizacija) svakog pojedinog zadatka kojeg generira scheduler.

Odgovor na prvo pitanje mora biti u skladu s načelnim pravilom da "masterbot nista ne zna", on samo prosljedjuje zahtjeve modulima. Zbog toga je izgradjen sistemski modul sched (sched-SysMod) koji od masterbota prima zahtjeve na uobičajeni način (preko stdin-a).

Kako međutim scheduler mora biti daemon, postoji još jedan program (schedd) koji se vrti bez prestanka i izvršava tabelirane zadatke.

Ljuska se dakle sastoji od dva programa u međuigri. Oni međusobno izmijenjuju podatke robustnim kanalima i djelatnom brzinom dobro ispod sekunde, a koji se kanali mogu u budućnosti mijenjati/unaprijedjivati bez ikakva utjecaja na sintaksu uporabe ljuske.

Sintaksa u Robotu verzije 1.00 jest:

sched add|del (t)imes=timelist[,(b)egin=time][,(e)nd=time],req="...."
sched del all|n=list
sched query

gdje su:
timelist = razmakom separirana lista (space separated list) vremena
time format = [DD[-MM[-[YY]YY]]/]hh[:mm[:ss]]
list = razmakom separirana (space separated) lista rednih brojeva zahtjeva kako su označeni u odgovoru naredbe query.
req = kompletni zahtjev kojeg treba izvršiti u naznačena vremena

Ako neki dijelovi vremena nisu navedeni, default se uzima iz trenutka kad je schedd primio zahtjev (datumski dio) odnosno 0 (vremenski dio). Npr. ako je zahtjev stigao SMS robotu dana 17.07.2003 onda:

Korisnikov unos Značenje
8 17-07-2003/08:00:00
08:05 17-07-2003/08:05:00
08:05:13 17-07-2003/08:05:13
08:5:13 17-07-2003/08:05:13
8:5:13 17-07-2003/08:05:13
22.05.03 22-05-2003/00:00:00
22-5-03 22-05-2003/00:00:00
15.04 15-04-2003/00:00:00
15.4 15-04-2003/00:00:00
22.5.2003/8:00 22-05-2003/08:00:00
22.5.2003./8:00 22-05-2003/08:00:00

Modul sched razaznaje slijedeće naredbe:
Naredba Značenje
add dodaj spomenuti zahtjev za spomenutog korisnika
set postavi spomenuti zahtjev kao jedini za spomenutog korisnika (eventualne ostale pobriši).
query izlistaj sve zahtjeve za spomenutog korisnika. Zahtjevi dobivaju redni broj.
del obriši zahtjev(e) specificiran(e) rednim broje(vi)m(a)
Primjer:

sched add time=07:15 14:10 19:25,req="ng report"

ovo ce slati svaki dan u naznacene sate rezultat requesta "ng report" bas kao da ga je korisnik poslao taj cas. Cijeli zahtjev dakako mora biti i autoriziran:

sched add tim=07:15 14:10 19:25,req="ng report" * dok qewt

Primijetimo da ce user "dok" biti efektivno pridodan zathjevima koje salje scheduler:

ng report * dok (authenticated)

Primijetimo da je jednokratna autentikacija korisnika dovoljna no scheduler će još provjeravati autoriziranost korisnika za svaku trazenu naredbu navedenu u parametru req.

Složeniji primjer:

sched add times=07:15 14:10 19:25,req="ng report $ reply sms n=098126538" * dok qewt

NAPOMENA. Vrijednosti parametara 'times' i 'req' mogu i ne moraju biti u navodnicima. No u posljednjem primjeru zbog znaka dolar u zahtjevu vrijednost parametra 'req' mora biti u navodnicima !

Parser

Parser je program koji može zahtjev u punoj standardnoj sintaksi (vidi Sintaksa zahtjeva Robotu ) rastaviti na sastavne dijelove: module, naredbe, parametre i vrijednosti parametara. Parser prima ulazni string preko standardnog inputa (stdin) te vraća parsirane elemente putem standardnog izlaza (stdout).
Sintaksa je:

${BOTPUB}/parser [-debug] < requestfile > outfile
ili
echo ' ...zahtjev... ' | ${BOTPUB}/parser > outfile

Svaki parsirani element je u jednom redu i u formatu: ime_elementa=vrijednost.
Evo kako to izgleda na primjeru:

echo ' imenik search pattern="Pero Peric" $ reply email address=mario@softhome.net $ auth login user=mario,pass=asdf ' | parser

Kao izlaz dobije se:

User=mario
Pass=axcv
Replyinfo=reply email address=mario@softhome.net
Modul=imenik
Cmd=search
Par=pattern
Value="Pero Peric"
Modul=reply
Cmd=email
Par=address
Value=mario@softhome.net
Modul=auth
Cmd=login
Par=user
Value=mario
Par=pass
Value=axcv

Parser je zamišljen da bude od koristi pri programiranju appmodova. Stoga osim što rastavlja zahtjev na sastavne elemente koji mogu biti od interesa u aplikacijskom modulu, u odgovoru se nalazi i polje "Replyinfo" čija se vrijednost jednostavno prenosi/predaje sistemskom modulu reply u svrhu slanja odgovora korisniku (vidi Pisanje aplikacijskih modula ).

Dodatak: definicija nekih pojmova

autentikacija, autorizacija, modul, naredba, parametar, vrijednost

  Brza pretraga

 
 Pomoć

Vaše primjedbe i upite o ovim stranicama izvolite uputiti elektroničkom poštom na: webmaster.
Copyright Š 2002-2003 Institut Ruđer Bošković
Last modified: Wed Mar 3 2004. 12:53:11 MET