I confuse easily, as you say freeipa works wonderfully well, then point out sun support to the api is hidden and it’s tricky to use. Do you mean Hadoop’s use is iffy?
If freeipa works wonderfully can we find the right api and sequence of calls, building our own model in image side? Then that model we compute on and it makes the right calls. Modeling is our strength, I have always thought. What is achievable? This would benefit ParrotTalk I think. - HH On Thu, Oct 26, 2017 at 16:28, philippe.b...@highoctane.be <philippe.b...@gmail.com> wrote: > There are two key Kerberos implementations one can use with Hadoop. > > One is the FreeIpa/RedHat IdM. > The other is ActiveDirectory. > > I am using FreeIPA which bundles MIT Kerberos/389/sssd and more for making a > CA etc. Works wonderfullý well. > > AD is well ... part of the corporate landdscape. > > Most of Kerberos needs are done with Java in Hadoop. But details are buried > in private Sun classes.. > > Google Madness beyond the gate hadoop for some Lovecraftian quotes describing > the situation along educated info. > > Phil > > On Oct 26, 2017 18:23, "henry" <he...@callistohouse.club> wrote: > >> I have no idea which is best. For being able to say we use industry standard >> Kerberos, calling an accepted implementation seems wise, like OpenSSL >> support. >> >> - HH >> >> On Thu, Oct 26, 2017 at 11:39, Paulo R. Dellani <dell...@pobox.com> wrote: >> >>> This all sounds very interesting. What is the idea? Wrap libkrb5 through >>> UFFI or implement it in Smalltalk? >>> >>> On 10/26/2017 04:38 PM, henry wrote: >>> >>>> A Kerberos effort will have to be a group effort. Sideways to my main >>>> focus and your all’s main focii. >>>> >>>> - HH >>>> >>>> On Thu, Oct 26, 2017 at 09:15, henry <he...@callistohouse.club> wrote: >>>> >>>>> I think another good service to integrate well to is Elastic Search. >>>>> >>>>> Of the 4 types of integration, I vote for and step forward to volunteer >>>>> to help Kerberos integration in Pharo. What to do? >>>>> >>>>> - HH >>>>> >>>>> On Thu, Oct 26, 2017 at 09:06, henry <he...@callistohouse.club> wrote: >>>>> >>>>>> I try posting with a smaller image. >>>>>> >>>>>> [""hubbub.jpg""] >>>>>> >>>>>> - HH >>>>>> >>>>>>> ——— Original Message ——— >>>>>>> Subject: Re: [Pharo-users] Smalltalk Argument >>>>>>> Local Time: October 26, 2017 8:52 AM >>>>>>> UTC Time: October 26, 2017 12:52 PM >>>>>>> From: he...@callistohouse.club >>>>>>> To: p...@highoctane.be >>>>>>> [<p...@highoctane.be>](mailto:p...@highoctane.be), Any question about >>>>>>> pharo is welcome >>>>>>> [<pharo-users@lists.pharo.org>](mailto:pharo-users@lists.pharo.org) >>>>>>> >>>>>>> Perhaps not, or not yet. Perhaps it is the communications foundation >>>>>>> for an always-on cloud/bigData control layer. >>>>>>> >>>>>>> I would position ParrotTalk as a Kerberos transport. ParrotTalk does >>>>>>> 2048-bin key negotiation and subsequent encryption/encoding, both >>>>>>> user-supplied. >>>>>>> >>>>>>> Please see the attached diagram, co-locating ParrotTalk with my other >>>>>>> components. >>>>>>> >>>>>>> ParrotTalk does not do user authentication/authorization. Which means >>>>>>> to me that I should consider Kerberos authorization/authentication to >>>>>>> establish as an integratable transport to play in bigData. >>>>>>> >>>>>>> This means you still need a Kerberos client and I need a Kerberos >>>>>>> client. How do we start? >>>>>>> >>>>>>> - HH >>>>>>> >>>>>>> PS: I did much work integrating Kafka into a framework. I was thinking >>>>>>> of inserting msg sending replication to a partition count of replicate >>>>>>> queues for sending and receiving Hubbub traffic, thus inserting right >>>>>>> where Kerberos is in the diagram. I would love to see client coupling >>>>>>> for Kerberos, Kafka and Hadoop, while I figure out proper security to >>>>>>> make that group happy with this as a possible control layer solution, >>>>>>> forking off jobs. >>>>>>> >>>>>>> On Thu, Oct 26, 2017 at 03:14, p...@highoctane.be <p...@highoctane.be> >>>>>>> wrote: >>>>>>> >>>>>>>> Sure. Current main issue is to have Pharo work with Kerberos as >>>>>>>> secured Hadoop uses the UGI (UserGroupInformation) thing and that is a >>>>>>>> black hole of crypto things. >>>>>>>> >>>>>>>> How would you see ParrotTalk work? >>>>>>>> >>>>>>>> I made a XmppTalk thing (binding for libstrophe) for having Pharo >>>>>>>> images and other stuff talk together (currently using >>>>>>>> OpenFire/Gajim/Profanity) FWIW >>>>>>>> >>>>>>>> See >>>>>>>> https://docs.google.com/presentation/d/1HTG3GB3xdwlje8wADZPjUQNIyA6tmuxyZz1UaX5ikEU/edit?usp=sharing >>>>>>>> >>>>>>>> libstrophe does the SSL thing under the hood (using OpenSSL) and is >>>>>>>> actively maintained. >>>>>>>> https://github.com/strophe/libstrophe/blob/master/src/tls_openssl.c >>>>>>>> >>>>>>>> And I currently work with Kafka so, Pharo as a consumer or producer, >>>>>>>> sure am interested. But need Kerberos support. >>>>>>>> >>>>>>>> Tell me more about your vision. Even better, draw it in some way :-) >>>>>>>> >>>>>>>> Phil >>>>>>>> >>>>>>>> On Thu, Oct 26, 2017 at 8:43 AM, henry <he...@callistohouse.club> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> This is a goal of ParrotTalk, to bring bit-compatible communications >>>>>>>>> to Squeak, Pharo and Java. This is not an invocation bridge you speak >>>>>>>>> of but a communications bridge to be able to run against Hadoop or >>>>>>>>> whichever big data needs integration with (Kafka). I had hoped it >>>>>>>>> might be adopted for such. Yet again this is not exactly what you >>>>>>>>> were looking for but yet interesting perhaps? >>>>>>>>> >>>>>>>>> - HH >>>>>>>>> >>>>>>>>> On Thu, Oct 26, 2017 at 02:17, p...@highoctane.be < >>>>>>>>> p...@highoctane.be> wrote: >>>>>>>>> >>>>>>>>>> I like that piece a lot, seeing exactly the described situation in >>>>>>>>>> large enterprises. >>>>>>>>>> >>>>>>>>>> I made a strategic decision to go with Pharo for the long run for my >>>>>>>>>> solutions because it is a stable base on which to build (ok, there >>>>>>>>>> are evolutions, but fundamentally, I can rely on it being under >>>>>>>>>> control and can maintain solutions in a version). >>>>>>>>>> >>>>>>>>>> The rationale is that at a deep level I am really fed up with having >>>>>>>>>> to deal with accidental complexity (now having to deal with >>>>>>>>>> Spark/Scala/sbt/Java/maven stuff) that makes the dev focus 80% >>>>>>>>>> technology drag and 20% net business contribution. >>>>>>>>>> >>>>>>>>>> One key thing is that a team needs guidance and Smalltalk makes it >>>>>>>>>> easier due to well known ways of doing things. >>>>>>>>>> >>>>>>>>>> Now we miss the boat on mobile and bigdata, but this is solvable. >>>>>>>>>> >>>>>>>>>> If we had an open Java bridge (and some people in the community have >>>>>>>>>> it for Pharo but do not open source it - so this is eminently >>>>>>>>>> doable) + Pharo as an embeddable piece (e.g. like Tcl and Lua) and >>>>>>>>>> not a big executable we would have a way to embed Pharo in a lot of >>>>>>>>>> places (e.g. in the Hadoop ecosystem where fast starting VMs and >>>>>>>>>> small footprint would make the cluster capacity x2 or x3 vs uberjars >>>>>>>>>> all over the place) this would be a real disruption. >>>>>>>>>> >>>>>>>>>> Think about being able to call Pharo from JNA >>>>>>>>>> https://github.com/java-native-access/jna the same way we use C with >>>>>>>>>> UFFI. >>>>>>>>>> >>>>>>>>>> Smalltalk argument for me is that it makes development bearable >>>>>>>>>> (even fun and enjoyable would I say) vs the other stacks. That >>>>>>>>>> matters. >>>>>>>>>> >>>>>>>>>> Phil
