5 ms·

Do you know the IP addresses of your servers? You shouldn't know them. That reveals a lack of automation at a pretty low level of your infrastructure. IP addre

Do you know the IP addresses of your servers? You shouldn't know them. That reveals a lack of automation at a pretty low level of your infrastructure. IP addresses change all the time in cloud environments and container orchestration systems. Even if they didn't change, you get better systems if you pretend they might. It doesn't matter if you use containers or not -- if you assume IP addresses could change at any time, you end up with infrastructure that is tied to your service graph rather than your hardware.

yardstick 7y ago
What about when the host is your domains dns server, and you need to ssh to it to fix a broken dns configuration. But because dns is broken the hostname you would use isn’t resolving anymore.
- vidarh 7y ago
  If a public domain, there needs to be NS records pointing at it from the registry, and they need to either have glue records giving the IP and/or at least one ought to be on a domain your name server itself is not the authoritative dns for. If a private domain and/or the server is only reachable from private IPs, then its IP should be in an asset management system somewhere (it should be if it is public too); be that a full blown orchestration system, if cloud servers or containers, or some form of asset register - even if only a spreadsheet - if it is physical servers in your own data centers. If properly automated, that asset register should drive configuration deployment - you shouldn't ssh to it to fix a broken dns configuration, you should run your deployment with a fixed config. I get that this is an idealized setup and that a lot of the time things intervenes and it's quicker and easier to do things manually then and there. Been there, done that, but in the long run it pays to invest the time in then cleaning that up (up to and including wiping clean setups that have been manually updated to verify that the automated setups are correct and complete).
jcelerier 7y ago
dude I'm not setting a DNS to access my NAS or my raspberry pi
- Dagger2 7y ago
  Then pick a memorable address, something like <prefix>::3 rather than <prefix>:ec47:87af:c904:98d7:de0b. If you refuse to pick a memorable address and refuse to use the tool which is designed to let you handle unmemorable addresses, then you don't get to complain about how hard your addresses are to remember.
  - MayeulC 7y ago
    This. If you look at my domain name (no nasty things, please): $ drill AAAA mayeul.net ;; ANSWER SECTION: mayeul.net. 900 IN AAAA 2a01:cb14:cce:1200::11 This isn't really hard to remember: I have the same prefix on the other computers on that network. Then 2a01:c000::/19 is my ISP's prefix [1]. The only part I picked was the :11, which is similar to the local IPv4 address I use on the same machine (10.12.186.11). I don't know the prefix by heart, but then I also get the v4 one wrong. I can get back the prefix from a DNS query most of the time, though. And I could create dummy subdomains to remember more address prefixes, if ever needed. If you need an IP address in multiple places on the same host, it would be better to use /etc/hosts anyways, or use a DNS server, as it makes changing configuration way easier. I've been playing around with the idea of giving each of my services a dedicated IPv6, so that I can seamlessly switch them from one machine to another. The very nice part is that I get more IP addresses than I will ever need. Probably. Unless I am into nanobots. I could take an IP address and reroute it over a tunnel, or even assign an address block the size of the whole IPv4 internet and make my server tunnel that to the right target. Waste IP addresses ranges just to get a convenient prefix (::f00d:7ea ::f00d:cafe for the teapot & coffee machine, for instance, or ::1:???? for pro stuff and ::6666:??? for personal things. I don't know). There are so many possibilities, I'm barely scratching the surface. Now, a couple minor complains I have: - I don't have IPv6 at work - My ISP doesn't have IPv6-enabled DNS - My ISP-provided router sometimes reset IPv6 firewall rules, which is annoying. [1]: https://www.ultratools.com/tools/ipv6InfoResult?ipAddress=2a01%3Acb14%3Acce%3A1200%3A%3A11 https://www.ultratools.com/tools/ipv6InfoResult?ipAddress=2a...
    - jcelerier 7y ago
      > This isn't really hard to remember: cmon, how many bits of information are there in your example vs remembering the last three digits of 192.168.1.xxx.
JohnClark1337 7y ago
Yes I know the ip address of my plex server, and my printer. I guess I'm a bad person.
eej2ya1K 7y ago
Almost every single web service in existence works or would work fine on a single server. We don't all need the cloud.
- mantoto 7y ago
  We are not going into the cloud for this reason. We go into the cloud because the cloud provided you infrastructure as a service which is a huge benefit for small and big companies.

yardstick 7y ago

What about when the host is your domains dns server, and you need to ssh to it to fix a broken dns configuration. But because dns is broken the hostname you would use isn’t resolving anymore.

vidarh 7y ago
If a public domain, there needs to be NS records pointing at it from the registry, and they need to either have glue records giving the IP and/or at least one ought to be on a domain your name server itself is not the authoritative dns for. If a private domain and/or the server is only reachable from private IPs, then its IP should be in an asset management system somewhere (it should be if it is public too); be that a full blown orchestration system, if cloud servers or containers, or some form of asset register - even if only a spreadsheet - if it is physical servers in your own data centers. If properly automated, that asset register should drive configuration deployment - you shouldn't ssh to it to fix a broken dns configuration, you should run your deployment with a fixed config. I get that this is an idealized setup and that a lot of the time things intervenes and it's quicker and easier to do things manually then and there. Been there, done that, but in the long run it pays to invest the time in then cleaning that up (up to and including wiping clean setups that have been manually updated to verify that the automated setups are correct and complete).

jcelerier 7y ago

dude I'm not setting a DNS to access my NAS or my raspberry pi

Dagger2 7y ago
Then pick a memorable address, something like <prefix>::3 rather than <prefix>:ec47:87af:c904:98d7:de0b. If you refuse to pick a memorable address and refuse to use the tool which is designed to let you handle unmemorable addresses, then you don't get to complain about how hard your addresses are to remember.
- MayeulC 7y ago
  This. If you look at my domain name (no nasty things, please): $ drill AAAA mayeul.net ;; ANSWER SECTION: mayeul.net. 900 IN AAAA 2a01:cb14:cce:1200::11 This isn't really hard to remember: I have the same prefix on the other computers on that network. Then 2a01:c000::/19 is my ISP's prefix [1]. The only part I picked was the :11, which is similar to the local IPv4 address I use on the same machine (10.12.186.11). I don't know the prefix by heart, but then I also get the v4 one wrong. I can get back the prefix from a DNS query most of the time, though. And I could create dummy subdomains to remember more address prefixes, if ever needed. If you need an IP address in multiple places on the same host, it would be better to use /etc/hosts anyways, or use a DNS server, as it makes changing configuration way easier. I've been playing around with the idea of giving each of my services a dedicated IPv6, so that I can seamlessly switch them from one machine to another. The very nice part is that I get more IP addresses than I will ever need. Probably. Unless I am into nanobots. I could take an IP address and reroute it over a tunnel, or even assign an address block the size of the whole IPv4 internet and make my server tunnel that to the right target. Waste IP addresses ranges just to get a convenient prefix (::f00d:7ea ::f00d:cafe for the teapot & coffee machine, for instance, or ::1:???? for pro stuff and ::6666:??? for personal things. I don't know). There are so many possibilities, I'm barely scratching the surface. Now, a couple minor complains I have: - I don't have IPv6 at work - My ISP doesn't have IPv6-enabled DNS - My ISP-provided router sometimes reset IPv6 firewall rules, which is annoying. [1]: https://www.ultratools.com/tools/ipv6InfoResult?ipAddress=2a01%3Acb14%3Acce%3A1200%3A%3A11 https://www.ultratools.com/tools/ipv6InfoResult?ipAddress=2a...
  - jcelerier 7y ago
    > This isn't really hard to remember: cmon, how many bits of information are there in your example vs remembering the last three digits of 192.168.1.xxx.

JohnClark1337 7y ago

Yes I know the ip address of my plex server, and my printer. I guess I'm a bad person.

eej2ya1K 7y ago

Almost every single web service in existence works or would work fine on a single server. We don't all need the cloud.

mantoto 7y ago
We are not going into the cloud for this reason. We go into the cloud because the cloud provided you infrastructure as a service which is a huge benefit for small and big companies.