README.md

SaaS

A bad idea, taken too far.

Or, the one true SaaS: /etc/services as a service!

Overview

Expanding upon a joke tweet, I set out to discover if you really could serve /etc/services over LDAP.

A helpful blog entry showed the schema elements needed, and the rest is proof you just can't take a bad joke too far.

Obligatory Gratuitous Animated GIF

Example

There's a public server available at ldap://services.brokenbottle.net, built from the server directory. (It's running on GKE, because that's the -aaSy way to do it in 2019, right?)

There's an example client, too:

$ docker run sveiss/saas-client getent services http
http                  80/tcp www www-http

This gives exactly the same result as executing the command locally (on a Fedora host, at least), but with Extra Cloud™!

If you really want to make your own machine talk to this, the client directory has what you need.

You can also speak LDAP to the server directly:

[stephen@drazi:~/hobby/saas]$ ldapsearch -x -H ldap://services.brokenbottle.net \
                                         -b dc=brokenbottle,dc=net cn=http
# extended LDIF
#
# LDAPv3
# base <dc=brokenbottle,dc=net> with scope subtree
# filter: cn=http
# requesting: ALL
#

# http + tcp, services, brokenbottle.net
dn: cn=http+ipServiceProtocol=tcp,ou=services,dc=brokenbottle,dc=net
objectClass: ipService
objectClass: top
cn: http
cn: www
cn: www-http
ipServicePort: 80
ipServiceProtocol: tcp

# http + udp, services, brokenbottle.net
dn: cn=http+ipServiceProtocol=udp,ou=services,dc=brokenbottle,dc=net
objectClass: ipService
objectClass: top
cn: http
cn: www
cn: www-http
ipServicePort: 80
ipServiceProtocol: udp

# http + sctp, services, brokenbottle.net
dn: cn=http+ipServiceProtocol=sctp,ou=services,dc=brokenbottle,dc=net
objectClass: ipService
objectClass: top
cn: http
ipServicePort: 80
ipServiceProtocol: sctp

# search result
search: 2
result: 0 Success

# numResponses: 4
# numEntries: 3

Yes, we even have HTTP over both SCTP and UDP covered!

Acknowledgements

Thanks to Nik Ogura, who's recent LDAP digging at work gave me sufficient context to bash this out in an evening of poor decisions, and to Ian Connolly for providing the inspiration by tweeting his frustrations!