Dostop do LotusNotes (Domino server) s Thunderbird?

Nastaviš POP protokol na Domino serverju ...

Drugače je pa Lotus Notes klient zastonj ...

In niti ne tako slab od verzije 8 naprej

Jaz bi raje uporabil IMAP namesto POP. ID datoteka je private key, ja.

Invictus je 18. nov 2011 ob 22:38 izjavil:

Nastaviš POP protokol na Domino serverju ...

Drugače je pa Lotus Notes klient zastonj ...

In niti ne tako slab od verzije 8 naprej

Kje imaš LN Client zastojn ?

@Invictus:
Bolj točno je, da je z verzijo 8 IBM za Domino prešel na CAL model. To pomeni, da je IBM prav vseeno s katerim odjemalcem dostopaš (LN klient, Browser, Thunderbird, Outlook,...) dokler imaš CAL licenco.

Zastonj je pa od 8.5 naprej Domino Designer, to je pa del poskusa da IBM malo bolj aktivira OSS community.

@Matthai: ID datoteka je private key, ID datoteka se uporablja samo za LND native (protokol NRPC) komunikacije. Drugi protokoli imajo security urejen po svoje. Ponavadi se v teh primerih avtenticiraš z uporabniškim imenom in geslom. Tu LND ne more nič kaj storit na transportnem nivoju (fino je uporabljat TLS protokole).

Kar se tiče enkripcije na serverju - LND security model je povsem identičen ne glede na to kako dostopaš do strežnika/baze. Torej enkripcija na strežniku nima nobene veze z transportnim protokolom.

@videc: Ne upravlja SRC vseh strežnikov - samo tiste, ki so v SVN domeni. Tako je po organih precej strežnikov in odjemalcev, ki so na LND pa nimajo nič s SRC.

Ja Matthai, najbolje da se obrneš na administratorje. A smem vprašat, zakaj ne uporabljaš lepo LN klienta? Boš imel precej manj težav s securityjem, POP in IMAP sta včasih malo čudna,...

Ja vem, da boš dejal da je klient hroščat in počasen (verjetno je na Linuxu še slabši), res je da Eclipse SUX major balls (1GB memorije za mail klient - ORLY?). ampak jaz do Domino serverja ne bi dostopal s tako inferiornimi protokoli kot je IMAP ali POP.

Na strežniku Lotus Domino potrebuješ imet kot prvo nameščen iNotes. Ta ti omogoča, da prek kateregakoli spletnega brskalnika dostopaš do tvoje Lotus pošte podobno, kot recimo do Gmaila. Mislim da uporabnik ne potrebuje nujno na računalniku ID datoteke, ampak se prijavi z uporabniškim imenom in geslom, ki je shranjeno v imeniku (meni so razlagali tudi o nekem password vaultu, ampak sem pozabil za kaj točno gre).

Moraš pa po moje imeti v primeru uporabe iNotes v vsakem primeru nastavljen policy, da morajo uporabniki gesla periodično menjati, kajti ko uporablaš klasičnega klienta, potrebuješ za dostop ID datoteko + geslo, prek spleta je dovolj uporabniško ime in geslo, kar je lahko varnostno precejšnja težava.

Nisem bral cele niti (govora je bilo nekaj o POP in IMAP, kar sta klasična poštna protokola). Vem da Lotus Domino strežniki že zelo dolgo podpirajo spletne storitve in se obnašajo tudi kot spletni strežnik (zaženeš http task na dominu), poštne baze pa so tudi že nekaj časa prirejene za dostop prek splete. Kaj točno iNotes naredi se nisem poglabljal, dejstvo je, da sedaj pošta prek spleta izgleda bistveno lepše. Za dostop do pošte prek mobilnih naprav (podobno kot Blackberry) pa mislim da potrebuješ še Travelerja.

Tule pa še Red Book od IBM na to temo (iNotes Web Access). Definitivno ne gre samo za design poštne baze.

Pa še nekaj. Jasno mi je, da Lotus ponuja več kot pošto. Samo uporabniki večinoma uporabljajo ZGOLJ pošto. Morda še koledar - za kar so dobre alternativne rešitve (iCal). In seveda zadnji IBM-ov "hit" - Sametime, ki je, če prav razumem malce napimpan XMMP.

Tako realno ne vidim kje je IBM-ova glavna prednost pred npr. Microsoftom ali odprtokodnimi rešitvami...

poweroff je 19. nov 2011 ob 12:02 izjavil:

Pa še nekaj. Jasno mi je, da Lotus ponuja več kot pošto...

Uporabniki uporabljajo to, kar jim IT omogoča. Lotus domino strežnik je mnogo več kot samo pošta. Omogoča ti razvoj zelo širokega spektra aplikacij in to bistveno hitreje, kot v marsikaterem drugem okolju. Deploy aplikacij največkrat pomeni samo da pošlješ uporabniki bližnjico prek maila, če gre za spletno aplikacijo pa URL itd.

Je pa res, da JU preprost ne zna izkoristiti tega, kar nudi pogodba z IBM. Lastnih razvijalcev večinoma nima nihče, pa čeprav je razvoj enostavnejših programov, ki lahko veliko olajšajo delo, skoraj trivialen, na trgu pa seveda vsaka malenkost stane par tisoč €, kar se zdi večini ogromno in odločno preveč. A isti so za Oracle aplikacijo takoj pripravljeni podpisati pogodbo za nekaj sto tisoč €.

Kar se tiče varnosti uporabljajo Lotus Notes organizacije, kot je FBI, tako da si lahko prepričan, da gre za dober produkt. Je pa res, da če se stvari lotiš amatersko, bodo rezultati tudi taki. Jaz sem bil priča v neki zavarovalnici (leta 99), ko je nekdo registriral uporabnike v Lotus Notes tako, da se je ID datoteka shranila v imenik za vsakega zaposlenega. Ko so v IT ugotovil, kakšna gesla je izbral, so lahko brali pošto praktično vsem zaposlenim. Ampak tu gre kot rečeno za amaterizem, ne problem IBM (takrat je bil to še Lotus).

ZaphodBB je 19. nov 2011 ob 12:17 izjavil:

To da uporabniki večinoma uproalbljajo zgolj pošto je predvsem IBMova krivda.

Globalno morda res, v naši JU pa nihče nikomur ne brani, da platformo uporablja tudi za aplikacije. Je pa res, da nekateri preprosto ne razumejo, da Lotus Domino ni SQL strežnik, kjer bi lahko razvijal neke računovodske aplikacije. Čudovito pa se obnese na področju upravljanja z dokumenti, sodelovanja itd. Kadar potrebuješ kakšno obdelavo tako zbranih podatkov, pa je enostavno narediti tudi izvoz v Excel.

Edino kar me je pri Lotus Notesu res negativno presenetilo je, da so slovenski črkovalnik v verziji 8 umaknili iz odjemalca na strežnik, pri čemur moraš baje za delovanje namestiti fat odjemalca (standard, ne basic), torej skupaj z eclipse.

Saj, kot pravim, je problem v tem, da te IBM sili v vendor lock-in. In to ima posledice pri varnosti. Če uporabljaš IZKLJUČNO njihove produkte, potem vse špila. (Razen v državni upravi, ampak to je druga zgodba).

Čim pa hočeš uporabiti kaj drugega - in ja, problem so danes zlasti telefoni - pa njihov silni security model pade. Ker ni standardiziran in ne zna sodelovat z rešitvami neodvisnih razvijalcev.

Res je sicer, da IBM po dveh letih pride in ponosno najavi, da imajo sedaj odjemalca za Androida, ampak to je natanko dve leti prepozno.

V primeru odprtokodnih rešitev sem lahko jaz na Androidu, Linuxu, Macu ali čem tretjem uporabljal šifriranje e-pošte praktično od začetka. OpenGPG je pač standard in je zato tudi široko podprt.

Da mi pa leta 2010 ali 2011 IBM marketing reklamira Sametime kot vrhunec tehnologije, pri čemer XMMP odjemalci to podpirajo že leta, prav tako Skype - je pa čisti nateg.

Ravno na tem primeru sem spoznal, kako zajeban je vendor lock-in. In ja, Microsoft ima sicer tudi podobno taktiko, ampak niso največji bad guy.


Kar se tiče iskanja po pošti. Saj deluje. Ampak ko kliknem tisti search gumb, me takoj prestavi v prejšnje stoletje. Thunderbird ali boh-ne-daj Outlook ima to veliko lepše izvedeno.

Mislim, kar res ne razumem je, zakaj je državna uprava šla na LotusNotes, pri čemer ga uporablja izključno za mail odjemalca (OK, SPIS je dokumentni sistem, ampak tisto je posebno "veselje")? Pa še to ne cela. Ministrstvo za finance je recimo šlo na Exchange... skratka, že tukaj ti pade "enotno okolje" in s tem silni security...

Se strinjam, Exchange v takem obsegu je fail. Takisto Active Directory (ki se uvaja v CELOTNO Univerzo v Ljubljani). Pravim pa, da že sedaj v državni upravi ni poenotenega sistema. Zato odpadejo razni miti o silni varnosti.

Tudi si drznem trditi, a HKOM ni tako varen, kot bi marsikdo želel prikazati, ampak to je druga zgodba.

Zanimivo pa, da nikogar ne moti izginjanje mailov, korupcije baz,... Samo da je lep vmesnik.

Mene to zelo moti. Na OBSTOJEČEM sistemu.

Spis je v na Dominu zgolj zaradi tega, ker je bil v letu 94 verjetno daleč najprimernejša platforma za tovrstne aplikacije. Na marsikaterem področju to velja še danes (Domino Directory je svetlobna leta pred AD).

Težav SPISa je pa več:
1. Vsebina - to je splošen problem vseh informacijskih sistemov po svetu. Tako so informatizirani procesi, praviloma zgolj mirror obstoječih fizičnih procesov, kar pogosto nima smisla in povzroča nepotrebne stroške v implementaciji. Pri pisanju zakonodaje se ne upošteva informacijskih sistemov, prav tako se masrikatera zakonodaja zaradi banalnosti spreminja prepogosto in v prevelikem obsegu, kar povzroča ogromne težave razvijalcem in vzdrževalcem teh sistemov. Za nameček se naši birokrati ne pogovarjajo med seboj, še posebaj kadar več organov sodeluje na istem projektu.
2. Tehnologija - SPIS je narejen na objekti bazi, kar omogoča hiter in poceni razvoj. To je dvorezen meč, ker vpleteni dobijo previsoka pričakovanja. Ravno tako razni tehnokrati v dobri veri želijo analitike, ki so povsem neprimerne za tovrsten tip baze[1], ti tehnokrati imajo ravno dovolj znanja da znajo razmišljati na relacijski način. A vendarle premalo, da bi bili sposobni doumeti omejitve tega pristopa.
3. Legacy: Spis je star 18 let, v tem času je šel skozi stotine iteracij, pogosto na horuk. Poleg tega organi ne upoštevajo napotkov o arhiviranju dokumentov in vztrajajo, da želijo celotno zgodovino v operativnih bazah. Tako, da se količina zapisov v aktivnih bazah gomili.
4. Zaščitna Shema: Zaščitna shema je hierarhičen ACL (šef vidi vse kar vidijo njegovi podrejeni, obratno pa ne). Hec je, da je zadeva pisana na kožo Dominu in laufa super dokler je dokumentov v bazi malo, ko začne zahteva rasti pa se pojavljajo težave (tovrstna preračunavanja so prekleto računsko zahtevna). Nahujši scenarij je, ko je v bazi miljone dokumentov, uporabnik pa jih vidi samo par ducat. Za povrh se zadevo zlorablja in se dostope drobi bolj kot bi bilo potrebno. Prištej še drugi del točke 3.

Spis še zelo dolgo ne bo šel nikamor (beri vsaj 10 let), bo pa v tem času 100% nekaj poskusov, da bi ga zamenjali z nečim na SQL serverju ali Oraclu. Projekti bodo delno implementirani klavrno propadli in povzročili večjo razdrobljenost ter enormne stroške.

Razlogov za mojo črnogledost je mnogo, od zgoraj navedenih težav, bodo vsi tekmeci soočeni z vsemi. V točki 2. pa se bo odprla povsem nova sfera agonije. Na to temo smo s kolegi svojčas izvedli celo serijo tehnoloških testov, ki so dali zelo zanimive rezultate.

[1]: ORM The Vietnam of Computer Science, če koga problematika podrobneje zanima.

Poleg SPIS je na Dominu recimo še VIZIS (VIZumski Informacijski Sistem), ki na Domino paše kot ata na mamo in spada med state of the art tovrstne sisteme na svetu. Potem so pa še kaki manjše aplikacije.

Sam ne delam več na Dominu, vendar je od vseh RAD platform katere sem videl, dejansko najbolje zamišljena in delujoča. Posledično pa ljudje od nje pričakujejo preveč.

ZaphodBB je 19. nov 2011 ob 16:54 izjavil:

Spis še zelo dolgo ne bo šel nikamor (beri vsaj 10 let), bo pa v tem času 100% nekaj poskusov, da bi ga zamenjali z nečim na SQL serverju ali Oraclu. Projekti bodo delno implementirani klavrno propadli in povzročili večjo razdrobljenost ter enormne stroške.

Uporaba Oracla je pa itak fail. Oracle je pač buzzword in v javni upravi (pa še marsikje drugje) navadno postanejo vsi mehki, ko slišijo to besedo. Zares bi bila pa upravičena uporaba v morda dveh organih.

Mar se pa tiče recimo DB2 rešitev... spet imaš problem priklenjenosti na IBM. Novih stvari ne moreš implementirati dokler jih veliki modri ne ponudi. In jih seveda drago kupiš.

Jaz sem recimo na MNZ serverjih oz. bazah odkril neko precej resno varnostno ranljivost. Gre v bistvu za cel class ranljivosti, ki se pojavlja povsod. Problem je v tem, da bo odprava stala enormno. Ker imajo v ozadju neko staro DB2 tehnologijo, ki ne omogoča enostavnega popravka. Možnosti imajo dve: da upogrejdajo IBM software (kar stane), ali pa da čarajo z nekimi dodatki in Oraclom, kar pa spet stane. Če bi imeli isto ranljivost in uporabljali odprtokodne rešitve, bi bil popravek skoraj trivialen.

Problem SPIS-a je seveda zastarelost. In to, da država nima strategije na tem področju. Obstajajo pa že dobre alternativne rešitve. Recimo ministrstvo za obrambo ima eno tako zanimivo rešitev, pa urad za preprečevanje pranja denarja. Pa tudi sistem od SOVE ni slab.

videc je 19. nov 2011 ob 17:36 izjavil:

O varnosti HKOM-a bodo pa verjetno v tem trenutku največ vedeli na Astecu. ;)

Se bojim da ne. Ko sem jim pred časom razlagal kje so težave so precej debelo gledali.

No, je pa res, da oni kot podizvajalec v resnici več kot toliko ne morejo narediti, čeprav bi pričakoval nekoliko večjo profesionalno skrbnost. Glavni problem so verjetno ljudje na MJU in v državni upravi, oziroma odsotnost kakršnekoli resne strategije na tem področju.

PRav zanimivo mi je bilo, ko sem pred kakšnim mesecem enemu izmed top varnostnih strokovnjakov enega tim. "državotvornega" organa demonstriral da fizični dostop do omrežja ne pomeni, da moram nujno v njihove prostore vstopiti...

@ZaphodBB: o hrenovkah si malo falil, pa pustimo. Ti pa verjetno delaš na SRC-u ali si delal tam. :)
Debata je bila o dostopu do Domino strežnika z Thunderbird odjemalcem. Ja, ne, kako...

dronyx je 19. nov 2011 ob 18:26 izjavil:

V gospodarstvu imajo te pojme se mi zdi dosti bolj razčiščene.

Zelo, ja. Sploh ko pošlješ par mailov, da bi rad kupil nek pošten server in je treba potem te privat firme po telefonu in po kolenih prosit, da ti vsaj blagovolijo poslat ponudbo. Na maile pa itak ni odgovora (brez klica).

Pač, Slovenija...

[1]: ORM The Vietnam of Computer Science, če koga problematika podrobneje zanima.

tole se pa strinjam. Ampak orm ima svoj prostor pod soncem ni pa univerzalna rešitev in tu so krivi precej programerji ker ga avtomatično tlačijo povsod kamor paše in kamor ne.

noraguta: Ali pa v relacijsko? Vseeno je v dokumentni bazi lažje modelirat hierarhijo kot v relacijski.

Glede RAD: kdo je govoril kaj o klientu? LN klient je zločin proti človeštvu po mojem mnenju. Ampak Domino Designer je pa zelo fajn orodje - če ostanemo na nivoju koncepta, ker hroščev raznih neumnih ima res dovolj.

@noraguta: Sej se mi je zdelo da imaš graf baze v mislih :)

Ampak poglej kakšen je domet povprečnega arhitekta/razvojnika na takih projektih :)

Če zna relacijsko bazo uporabit je že kr kralj. Kamoli, da bi žongliral tri različne paradigme :).

ZaphodBB je 19. nov 2011 ob 20:42 izjavil:

@noraguta: Sej se mi je zdelo da imaš graf baze v mislih :)

Ampak poglej kakšen je domet povprečnega arhitekta/razvojnika na takih projektih :)

Če zna relacijsko bazo uporabit je že kr kralj. Kamoli, da bi žongliral tri različne paradigme :).

matr sej to so študiran ljudje. al še vedno velja na naših faxih u šolo hod da ti nav treba delat , pa mi te nebomo nič naučil samo preverl bomo kolk dreka lohk poješ.
pa saj načeloma bi morala platforma ponujat lahkotno integracijo različnih konceptov. .net-u manjka prav soliden graphdb. z jsonom štrikat je fajn za manjše projekte potem se ti pa zagabi fleksibilnost, ko vidiš, da si tipi nimaš kaj pomagat ,ko dobiš tujo kodo. Z javo se da marsikaj , ampak nima pod sabo kaj podobnega kot sta AD, Exchange , Sharepoint kateri vsak na svojem koncu ponujajo soliden paket funkcionalnosti sploh če upoštevamo še integracijo z desktop device-i(pri mobilnih pa še ti šepajo).
Couchdb je sicer dober documentstore ampak to in samo to,ok za offline sinhronizacijo je super.

Sam sem nakoncu dojel , da drobljenje produktov niti ni tako napačno je pa potem jeba integracija.

noraguta: A ti sploh veš, da 90% stvari o katerih govoriš ni obstajal deset let nazaj?

Kar se pa LDAP tiče, zadeva je bla čisto tko zastavljena kot ti predlagaš. Vsi so se držal dogovora razen MS.

ZaphodBB je 19. nov 2011 ob 21:58 izjavil:

noraguta: A ti sploh veš, da 90% stvari o katerih govoriš ni obstajal deset let nazaj?

Kar se pa LDAP tiče, zadeva je bla čisto tko zastavljena kot ti predlagaš. Vsi so se držal dogovora razen MS.

vem ampak to ni razlog za vztrajanje na LN dan danes, po drugi strani ja vse znanje kateri je danes zdrušeno pod noSql staro 20 do 30 let sybase je imel pa še takrat precj napredne rešitvee samo v corporate sektor ga niso spustili.

glede ldapa , pa ni glih tko simpl , tud ob pametnih predlogih so MS blokiral pri pripombah, na konc so pač nardil stvar katera je vsaj zasilo sprejemljiva ni pa pravoverna. na koncu zadeva še vedno izvira iz x500-ke pa bi bila potrebna poštene prevetritve.

ZaphodBB je 20. nov 2011 ob 08:38 izjavil:

@noraguta: Zamenjava enega sistema kot je Spis tud ni trivialno početje. Poleg tega, ko bo do zamenjave prišlo - se definitvno ne bo delalo na CouchDB, Mongu ali čem podobnem. Vzelo se bo SQLServer, DB2 ali pa Oracle - kar bo katastrofa.

Saj obstaja rešitev, ki je konkurenca SPIS in sicer GovernmentConnect firme Marg, ki za shranjevanje podatkov uporablja relacijsko bazo (mislim da MS SQL) in uporablja spletni vmesnik za dostop. Uporabljajo jo pa na Ustavnem sodišču in tudi na MORS, kjer je več tisoč uporabnikov (baje).

Ravnno to zadevo od Marga sem hotel omeniti. Ne vem, ampak bo treba več obarazložitve kot zgolj "Garantiram ti, da zadeva ni niti blizu SPIS".

Kar se tiče SPIS-a... res je, včasih se bolj splača face lifting. Ampak če je stvar zgrešena že v osnovi se najbolj splača narediti (boleč a nujen) rez. SPIS je pač aplikacija izpred 10 let. Into se ji konkretno pozna.

poweroff je 20. nov 2011 ob 16:05 izjavil:

Kar se tiče SPIS-a... res je, včasih se bolj splača face lifting. Ampak če je stvar zgrešena že v osnovi se najbolj splača narediti (boleč a nujen) rez. SPIS je pač aplikacija izpred 10 let. Into se ji konkretno pozna.

Jaz zadevo s SPISom kar dobro poznam, ker sem dvakrat sodeloval pri uvedbi te rešitev. Največji problem pa po moje sploh ni SPIS kot tak. Uvedba take rešitve je predvsem velik organizacijski zalogaj, ki bi moral spremeniti način dela, kar pa naleti dostikrat na velik odpor. Taka rešitev, ki ti dejansko omogoča elektronsko - brezpapirno poslovanje, je podobna sprememba, kot ko so računalniki zamenjali po ministrstvih t.i. strojepisnice (sobe, kjer je bilo nekaj pisalnih strojev in so hodili ljudje narekovat strojepiskam dopise). Takrat je tudi marsikateri zaposleni debelo pogledal, češ, kaj bom sedaj sam tipkal dopise? Druga težava pa je v nerazumevanju, da vsaka taka informacijska rešitev zahteva tudi izobraževanje zaposlenih, za kar pa mislim da je denarja čedalje manj, oziroma ga sploh ni več.