So management is insisting that we migrate our openLDAP systems from on premise into the cloud <sigh>. Specifically, AWS behind one of their load balancers.
However, we currently rely upon some level of IP address based access control to distinguish between on-campus and off-campus clients. The Amazon load balancers do client NAT, so the back end servers have no idea who is connecting at the TCP/IP level.
They do support the haproxy in band protocol for supplying this information from the load balancer to the server, but that requires specific support from the server to do. I don't see any such support in openldap or any evidence of past discussion regarding it.
Is this something that would be considered as a possible feature to be included at some point, or something not desired as part of the code base?
Thanks...
Paul B. Henson wrote:
So management is insisting that we migrate our openLDAP systems from on premise into the cloud <sigh>. Specifically, AWS behind one of their load balancers.
However, we currently rely upon some level of IP address based access control to distinguish between on-campus and off-campus clients. The Amazon load balancers do client NAT, so the back end servers have no idea who is connecting at the TCP/IP level.
They do support the haproxy in band protocol for supplying this information from the load balancer to the server, but that requires specific support from the server to do. I don't see any such support in openldap or any evidence of past discussion regarding it.
Is this something that would be considered as a possible feature to be included at some point, or something not desired as part of the code base?
Depends on what that feature actually looks like. Feel free to submit a proposal on the -devel mailing list, including background info on what HAproxy protocol looks like, and what exact behaviors you want it to provide.
http://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
for reference.
From: Howard Chu hyc@symas.com Date: Wednesday, November 18, 2020 at 8:51 AM To: Paul B. Henson henson@acm.org, openldap-technical@openldap.org openldap-technical@openldap.org Subject: Re: HAProxy protocol support? Paul B. Henson wrote:
So management is insisting that we migrate our openLDAP systems from on premise into the cloud <sigh>. Specifically, AWS behind one of their load balancers.
However, we currently rely upon some level of IP address based access control to distinguish between on-campus and off-campus clients. The Amazon load balancers do client NAT, so the back end servers have no idea who is connecting at the TCP/IP level.
They do support the haproxy in band protocol for supplying this information from the load balancer to the server, but that requires specific support from the server to do. I don't see any such support in openldap or any evidence of past discussion regarding it.
Is this something that would be considered as a possible feature to be included at some point, or something not desired as part of the code base?
Depends on what that feature actually looks like. Feel free to submit a proposal on the -devel mailing list, including background info on what HAproxy protocol looks like, and what exact behaviors you want it to provide.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
We did so as well (and would really like the haproxy support). Actually, we have a hybrid model with but with more replicas in the cloud than on-prem. It mirrors a general push to have the services which reply on LDAP to also be in the cloud. I guess one advantage is that if/when we need more resources to support demand, it is just a question of money rather than acquiring physical resources, finding rack space, etc. I don’t know that it actually any cheaper, but it is more immediate.
On Nov 18, 2020, at 3:35 PM, Marc Roos M.Roos@f1-outsourcing.eu wrote:
So management is insisting that we migrate our openLDAP systems from on premise into the cloud
If I maybe totally off topic. Why would they, for what reasons?
// John Pfeifer Division of Information Technology University of Maryland, College Park
On 11/18/2020 12:47 PM, John C. Pfeifer wrote:
We did so as well (and would really like the haproxy support).
I posted the requested message to the dev list, if it sounds like something they would accept I'll probably take a run at implementing it.
Actually, we have a hybrid model with but with more replicas in the cloud than on-prem.
Yes, technically, we are probably going to have a split service too, with on-campus clients hitting the on-campus service and off-campus clients hitting the off-campus service, with failover between them if one or the other is dead.
It mirrors a general push to have the services which reply on LDAP to also be in the cloud.
The cloud is magic, right ;)? At least, it magically assists in manager CYA when stuff breaks 8-/, blame it on Amazon…
I guess one advantage is that if/when we need more resources to support demand, it is just a question of money rather than acquiring physical resources, finding rack space, etc. I don’t know that it actually any cheaper, but it is more immediate.
Once upon a time the whole cloud migration was pushed as a cost savings measure. Over time, it's become clear it's quite the opposite. I think the current claim to fame is "reliability and redundancy", along with "supernatural scaling ability".
IMHO, the "cloud" is just somebody else's physical data center you have minimal control over <sigh>. If I had a nickel for every time my manager told me "it's less than ideal, but we could [...]" in regards to our cloud migration I could retire and stop having to hear him say it ;).
Paul B. Henson wrote:
On 11/18/2020 12:47 PM, John C. Pfeifer wrote:
It mirrors a general push to have the services which reply on LDAP to also be in the cloud.
The cloud is magic, right ;)? At least, it magically assists in manager CYA when stuff breaks 8-/, blame it on Amazon…
I guess one advantage is that if/when we need more resources to support demand, it is just a question of money rather than acquiring physical resources, finding rack space, etc. I don’t know that it actually any cheaper, but it is more immediate.
Once upon a time the whole cloud migration was pushed as a cost savings measure. Over time, it's become clear it's quite the opposite. I think the current claim to fame is "reliability and redundancy", along with "supernatural scaling ability".
IMHO, the "cloud" is just somebody else's physical data center you have minimal control over <sigh>. If I had a nickel for every time my manager told me "it's less than ideal, but we could [...]" in regards to our cloud migration I could retire and stop having to hear him say it ;).
The cloud sort of made sense if you were entirely compute bound, and just wanted to spin up a few more CPUs to handle a dynamic spike in load. It has never made sense for database services, where adding CPUs won't help if you're getting bottlenecked by storage access. You can't just spin up a few more terabytes of pre-populated disk, it takes non-trivial time to duplicate a DB (if your system will even function correctly using separate complete copies of the DB), or to re-shard the DB if your system supports sharding.
--On Wednesday, November 18, 2020 5:56 PM -0800 "Paul B. Henson" henson@acm.org wrote:
The cloud is magic, right ;)? At least, it magically assists in manager CYA when stuff breaks 8-/, blame it on Amazon…
Once upon a time the whole cloud migration was pushed as a cost savings measure. Over time, it's become clear it's quite the opposite. I think the current claim to fame is "reliability and redundancy", along with "supernatural scaling ability".
IMHO, the "cloud" is just somebody else's physical data center you have minimal control over <sigh>.
Yeah, the "minimal control" is a serious problem, since Amazon can do things you've no idea about and take down everything you're doing without warning.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
"Marc Roos" M.Roos@f1-outsourcing.eu schrieb am 18.11.2020 um 21:35 in
Nachricht <"H0000071001853f4.1605731735.sx.f1-outsourcing.eu*"@MHS>:
So management is insisting that we migrate our openLDAP systems from
on premise into the cloud
If I maybe totally off topic. Why would they, for what reasons?
I could imagine five resaons:
1) Because it seems to be "cool" to put your data into the cloud (consultants may advise)
2) Management is not happy with the realiability right now
3) Reliability is good, and management expects it not to get worse in thge cloud
4) Management thinks the cloud will "work by itself" and they want to fire a few people taking care of the infrastructure right now.
5) Management is bored, and they are seeking for some thrill...
Regards, Ulrich
Am 19.11.2020 um 08:17 schrieb Ulrich Windl:
"Marc Roos" M.Roos@f1-outsourcing.eu schrieb am 18.11.2020 um 21:35 in
Nachricht <"H0000071001853f4.1605731735.sx.f1-outsourcing.eu*"@MHS>:
So management is insisting that we migrate our openLDAP systems from
on premise into the cloud
If I maybe totally off topic. Why would they, for what reasons?
I could imagine five resaons:
Because it seems to be "cool" to put your data into the cloud (consultants may advise)
Management is not happy with the realiability right now
Reliability is good, and management expects it not to get worse in thge cloud
Management thinks the cloud will "work by itself" and they want to fire a few people taking care of the infrastructure right now.
Management is bored, and they are seeking for some thrill...
:-)
A non imaged and IMO good reason for not doing cloud, is that LDAP servers generally have personally identifyable information such as sn, givenname, email, etc. At least in countries that honor privacy legislation such as GDPR, you don't want such data under the control of another company and you do want to know where exactly such data are stored under which jurisdiction.
My 2 Cent.
Cheers,
Peter
Regards, Ulrich
openldap-technical@openldap.org
-
Dr. Ogg -
Howard Chu -
John C. Pfeifer -
Marc Roos -
Paul B. Henson -
Peter Gietz -
Quanah Gibson-Mount -
Ulrich Windl