I refer to it as “Craptive Directory”, the only reliable way I’ve found to use it is to federate it via WSO2 IS or OpenIDM.
You forgot Sun’s implementation, btw, which is cleaner than either. Sent from Mail for Windows 10 From: p...@highoctane.be Sent: Thursday, October 26, 2017 6:07 PM To: henry; Any question about pharo is welcome Subject: Re: [Pharo-users] Smalltalk Argument 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. - 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>, Any question about pharo is welcome <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
