[heroes] Re: [#59920] New DNS infrastructure for openSUSE domains
Lars, thanks for driving this. On 1/13/20 11:56 PM, admin@opensuse.org wrote:
[openSUSE Tracker] Issue #59920 has been updated by lrupp.
% Done changed from 20 to 60
ns1.opensuse.org and ns2.opensuse.org are online and answer queries for the opensuse.org domain.
left TODO: * define a machine outside the Nuremberg network as DNS * saltify the setup
Do you still want some help? IIRC you've installed bind. At heroes meeting there was a tendency to go for PowerDNS. Backend was still to be decided. I have some preference for launch=ldap to have authc/authz integration to another LDAP server [1] and use native LDAP replication for HA. But maintaining DNSSEC RRs with pdns_control is probably not yet supported by PowerDNS' LDAP backend. I've tried to login to nue-ns1.infra.opensuse.org to have a look at the current setup but are probably not allowed to do so. Ciao, Michael. [1] https://www.ae-dir.com/apps.html#slapd-ldap -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org
Hi Michael
Am January 17, 2020 5:57:44 PM UTC schrieb "Michael Ströder"
Do you still want some help?
Yes, please! :-) We can even deploy additional DNS in Provo or on slimhat (so using different data centers). With a DNS in Provo, we could even think about how-based DNS (later). DNSsec or DNS over http and all the other "playgrounds" should also be on the table... ...and please do not forget that we could fill a book with the "Best practices to run openSUSE (in your) infrastructure" topic. I know some people who are interested to run their infra based on our documented setup! So someone should start to write a bestseller :-)
IIRC you've installed bind. At heroes meeting there was a tendency to go for PowerDNS. Backend was still to be decided.
As I wrote: I installed bind because I know it and I see the pressure to have something up and running to become independent. But I
I have some preference for launch=ldap to have authc/authz integration to another LDAP server [1] and use native LDAP replication for HA.
While I'm more a fan of KISS (means here: having a single, independent service which could run without any outside dependencies - so I would have the data in ldap, but use a local dump), this could of course also be done - and there are people like you, who have a way better knowledge than me on how to do this right. :-) The initial setup should definitively improve over time. And those who do decide.
I've tried to login to nue-ns1.infra.opensuse.org to have a look at the current setup but are probably not allowed to do so.
You could. But I have to admit that I did not really much to make this easy for you: I only got the machine known by the saltmaster and made sure that the machine accepted the saltmaster for deployments. The rest is on you... ;-). => Just add your ssh-key via Salt. If unsure, just ask how this can be done, and I'm sure that Christian (aeh: someone) is able to help. :-)) Regards, Lars -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org
Hello, Am Freitag, 17. Januar 2020, 22:18:26 CET schrieb Lars Vogdt:
Am January 17, 2020 5:57:44 PM UTC schrieb "Michael Ströder":
Do you still want some help?
Yes, please! :-) We can even deploy additional DNS in Provo or on slimhat (so using different data centers). With a DNS in Provo, we could even think about how-based DNS (later). DNSsec or DNS over http and all the other "playgrounds" should also be on the table... ...and please do not forget that we could fill a book with the "Best practices to run openSUSE (in your) infrastructure" topic. I know some people who are interested to run their infra based on our documented setup! So someone should start to write a bestseller :-)
;-) Feel free to copy&paste whatever you consider interesting in this mail to the admin wiki ;-)
IIRC you've installed bind. At heroes meeting there was a tendency to go for PowerDNS. Backend was still to be decided.
As I wrote: I installed bind because I know it and I see the pressure to have something up and running to become independent. But I
Looks like you wanted to write a bit more here?
I have some preference for launch=ldap to have authc/authz integration to another LDAP server [1] and use native LDAP replication for HA. While I'm more a fan of KISS (means here: having a single, independent service which could run without any outside dependencies - so I would have the data in ldap, but use a local dump), this could of course also be done - and there are people like you, who have a way better knowledge than me on how to do this right. :-) The initial setup should definitively improve over time. And those who do decide.
... and this is why it's unlikely that we'll end up with text/plain zone files ;-) - while I'd prefer them (to keep things simple), I probably won't have time to work on the DNS setup.
I've tried to login to nue-ns1.infra.opensuse.org to have a look at the current setup but are probably not allowed to do so.
You could. But I have to admit that I did not really much to make this easy for you: I only got the machine known by the saltmaster and made sure that the machine accepted the saltmaster for deployments. The rest is on you... ;-).
It would be nice to at least run highstate after setting up a new VM. This does some basic setup, for example the ssh and sssd config that allows ssh logins for FreeIPA users, configuring syslog to log to monitor.o.o etc. Note: If your new VM has a role assigned, you'll need to run a second highstate - the first highstate adds the role to /etc/salt/grains, the second actually applies the "content" of that role. (#62204 makes things slightly ;-) more interesting, but that's a different story.) I just did the highstate for nue-ns{1,2}, therefore everybody with a heroes account should be able to ssh to these machines now. (I'd be surprised if the base setup from salt breaks something in the bind setup, but since I don't know much about bind, please check yourself.) Note that this base setup does not include sudo permissions. If someone submits a MR to our salt repo that adds sudo permissions to a role (the existing ns_slave role uses powerdns and probably doesn't fit, maybe a new role?), I'll happily review that ;-)
=> Just add your ssh-key via Salt.
No, please don't ;-) (unless you have very good reasons [1]) Our usual workflow is to setup a group in FreeIPA (in this case probably "dns-admins"), and then setup a sudo rule for this group in salt (in pillar/role/*). However, I wonder if it makes sense to keep this level of indirection, or if we should switch to listing individual users in salt. The only disadvantage is that we'll have to do a highstate when we add permissions for someone, while we currently only have to do this once to write the sudo rules for the $whatever-admins group. IMHO getting rid of a level of indirection is probably worth that ;-)
If unsure, just ask how this can be done, and I'm sure that Christian (aeh: someone) is able to help. :-))
;-) Regards, Christian Boltz [1] For example, my ssh key is on minnie so that I can login there even if sssd is on "vacation", and can then restart sssd everywhere via salt. -- If nothing else, the 15 years I've been online have impressed upon me the ability of people to be offensive in new and inventive ways. [Joe 'Zonker' Brockmeier in opensuse-marketing] -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org
On 1/18/20 7:12 PM, Christian Boltz wrote:
Am Freitag, 17. Januar 2020, 22:18:26 CET schrieb Lars Vogdt:
As I wrote: I installed bind because I know it and I see the pressure to have something up and running to become independent. But I
Ok, understood.
I have some preference for launch=ldap to have authc/authz integration to another LDAP server [1] and use native LDAP replication for HA. While I'm more a fan of KISS (means here: having a single, independent service which could run without any outside dependencies - so I would have the data in ldap, but use a local dump), this could of course also be done - and there are people like you, who have a way better knowledge than me on how to do this right. :-) The initial setup should definitively improve over time. And those who do decide.
... and this is why it's unlikely that we'll end up with text/plain zone files ;-) - while I'd prefer them (to keep things simple), I probably won't have time to work on the DNS setup.
Zone files look simple until you look at other requirements: HA: AXFR is not always super-reliable and needs increasing the serial number. The latter is more hard to do with zone files in an automated way (and is often forgotten during manual editing). => Native database replication works better. Scripting: E.g. for Let's Encrypt integration you might want to dynamically add and remove DNS RRs without mucking with DNS-Update (RFC 2136). Not to speak of authc/authz deficiencies... => native DB access is better Ciao, Michael. -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org
On 1/18/20 8:06 PM, Michael Ströder wrote:
On 1/18/20 7:12 PM, Christian Boltz wrote:
Am Freitag, 17. Januar 2020, 22:18:26 CET schrieb Lars Vogdt:
As I wrote: I installed bind because I know it and I see the pressure to have something up and running to become independent. But I
Ok, understood.
I have some preference for launch=ldap to have authc/authz integration to another LDAP server [1] and use native LDAP replication for HA. While I'm more a fan of KISS (means here: having a single, independent service which could run without any outside dependencies - so I would have the data in ldap, but use a local dump), this could of course also be done - and there are people like you, who have a way better knowledge than me on how to do this right. :-) The initial setup should definitively improve over time. And those who do decide.
... and this is why it's unlikely that we'll end up with text/plain zone files ;-) - while I'd prefer them (to keep things simple), I probably won't have time to work on the DNS setup.
Zone files look simple until you look at other requirements:
HA: AXFR is not always super-reliable and needs increasing the serial number. The latter is more hard to do with zone files in an automated way (and is often forgotten during manual editing). => Native database replication works better.
Scripting: E.g. for Let's Encrypt integration you might want to dynamically add and remove DNS RRs without mucking with DNS-Update (RFC 2136). Not to speak of authc/authz deficiencies... => native DB access is better
I can understand that PowerDNS with LDAP backend sounds complex but it isn't. (Now, "Butter bei de Fische...") This is more or less what I'm using for my own internal auth DNS servers for configuring OpenLDAP as DNS-backend and have password-based authc and the authz done via back-ldap to Æ-DIR (or any other LDAP server): https://gitlab.com/ae-dir/client-examples/blob/master/slapd-ldap/slapd.conf The multi-master replication config part will take two more config statements. But that's it. Lines added to default config of PowerDNS authorative server (file /etc/pdns/pdns.conf) for launching the LDAP backend: ldap-host=ldapi:// ldap-starttls=no ldap-basedn=cn=pdns,dc=example,dc=com ldap-binddn=cn=pdns,dc=example,dc=com ldap-secret=supersecretsyspassword ldap-method=simple That's it for the config. For each hosted domain you have add a SOA RR entry like this: dn: associatedDomain=vnet1.local,ou=pdns,ou=infra,dc=stroeder,dc=de associatedDomain: vnet1.local dc: vnet1 hasSubordinates: TRUE nSRecord: nb2.stroeder.local objectClass: dNSDomain2 objectClass: domainRelatedObject rPRecord: hostmaster.stroeder.com. updatensa.system. sOARecord: nb2.stroeder.local. hostmaster.stroeder.com. 2 10800 3600 604800 86400 An A RR looks like this: dn: dc=samba1,associatedDomain=vnet1.local,ou=pdns,ou=infra,dc=stroeder,dc=d e aRecord: 10.54.1.93 associatedDomain: samba1.vnet1.local dc: samba1 description: Samba CentOS7 test system objectClass: dNSDomain2 objectClass: domainRelatedObject The accompanying PTR RR looks like this: dn: dc=93,associatedDomain=1.54.10.in-addr.arpa,ou=pdns,ou=infra,dc=stroeder ,dc=de associatedDomain: 93.1.54.10.in-addr.arpa dc: 93 description: Samba CentOS7 test system objectClass: dNSDomain objectClass: dNSDomain2 objectClass: domainRelatedObject pTRRecord: samba1.vnet1.local My web2ldap already contains plugin classes to make maintaining the stuff a bit more easy. The only caveat with using LDAP backend is that DNSSEC is probably not directly supported yet (in opposite to the various SQL backends). Feedback welcome. Ciao, Michael. P.S.: I'm also using LDAP server as backend for ISC dhcpd. -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org
On 1/18/20 7:12 PM, Christian Boltz wrote:
Am Freitag, 17. Januar 2020, 22:18:26 CET schrieb Lars Vogdt:
Michael Ströder wrote:
I've tried to login to nue-ns1.infra.opensuse.org to have a look at the current setup but are probably not allowed to do so.
You could. But I have to admit that I did not really much to make this easy for you: I only got the machine known by the saltmaster and made sure that the machine accepted the saltmaster for deployments. The rest is on you... ;-).
It would be nice to at least run highstate after setting up a new VM. This does some basic setup, for example the ssh and sssd config that allows ssh logins for FreeIPA users, [..] [..] Note that this base setup does not include sudo permissions. If someone submits a MR to our salt repo that adds sudo permissions to a role (the existing ns_slave role uses powerdns and probably doesn't fit, maybe a new role?), I'll happily review that ;-)
=> Just add your ssh-key via Salt.
No, please don't ;-) (unless you have very good reasons [1]) [..] Our usual workflow is to setup a group in FreeIPA (in this case probably "dns-admins"), and then setup a sudo rule for this group in salt (in pillar/role/*).
However, I wonder if it makes sense to keep this level of indirection, or if we should switch to listing individual users in salt.
This all sounds really odd to me. :-/ Why not just use a decent user management for all of that and maintain access control data just in the database? :-] Ah, it's already there: https://aedir1.infra.opensuse.org/ Everybody interested in testing this, just drop me an e-mail with your person name and e-mail address you want to use for registration. Ciao, Michael. -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org
participants (3)
-
Christian Boltz -
Lars Vogdt -
Michael Ströder