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 Thu, Oct 26, 2017 at 6:23 PM, 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. > > [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> <p...@highoctane.be>, Any > question about pharo is welcome <pharo-users@lists.pharo.org> > <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/1HTG3GB3xdwlje8wADZPjUQNIyA6tm > uxyZz1UaX5ikEU/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-na > tive-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 > >
