Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
nndocs [2018/09/28 22:45]
naptastic correct and update page descriptions
nndocs [2019/05/11 23:01] (current)
naptastic [Design Decisions And Conventions]
Line 1: Line 1:
 ===== Naptastic Network Documentation ===== ===== Naptastic Network Documentation =====
  
-These pages contain instructions I've written to myself, which I think you might also find useful. The instructions explain how to reproduce certain configurations and results that I've accomplished before, so that I don't have to figure them out all over again the next time they'​re needed.+Main Goals 
 +  * Zero points of failure 
 +  * Off-site backups with Hanoi retention policies 
 +  * Virtualize everything possible using OpenStack 
 +  * What else?
  
-You might think of it as a form of cachinginstead ​of recalculating ​the steps to an ideal configuration, I fetch the instructions ​from the cache and just execute them.+Gotta track what I already have. 
 +  * What's already automated?​ 
 +    * (nothing) 
 +    * How are we  
 +  * What's already documented?​ 
 +    * (the old stuff below) 
 +  * What am I already doing and what does it get me? (Besides what's already documented) 
 +    * shorewall 
 +    * isc-dhcp-server 
 +    * PXE live environment 
 +    * custom kernels (tbh I haven'​t kept up on these almost at all and could probably do better with  
 +  * What do I want that I don't have yet, and what do I have to do to get it? 
 +    * **Most important of all**, this needs to be set up so people can work on different tasks simultaneously and independently. 
 +    * Better provisioning for bare-metal hosts. 
 +    * Better configuration management. 
 +    * VPN 
 +    * OpenStack: Each site is an availability zone 
 +    * Backups: Fully automatic including tests; Hanoi retention 
 +    * MySQL replication,​ HA, failover. 
 +    * Virtualize everything that makes sense to do so. 
 +  * What am I doing that doesn'​t help me anymore? 
 +    * VirtualBox 
 +    * (probably) compiling so much stuff from source 
 + 
 +==== Design Decisions And Conventions ==== 
 + 
 +The network is numbered 172.x.y.z, where x is a location, y is a host, and z is a guest or additional IPs. While we're only handing out /16's per location right now, we might want to hand out larger allocations at some point. We also want to leave options open for locations to expand in the future without exploding our routing tables. So when we add locations, we will subdivide the largest chunk available unless we've got a really good reason not to. When we expand allocations to a house that already has a /16, we should have room to just make it a /15. Or more. But if we really need that many IPs, we should figure out how to IPv6. 
 + 
 +  * 172.x.0.1 is reserved for location routers. A router may have multiple 172.x.0.1 addresses, and will have an external IP as well. 
 +    * 16/16 : Reserved for OpenStack 
 +    * 17/16 : Reserved for Docker (Apparently?​) 
 +    * 20/16 : narf.rocks 
 +    * 24/16 : (next available spot; maybe zoit.rocks rises again?) 
 +    * 28/16 : freaksavior.com 
 + 
 +So, we can grow in terms of locations, or networks per location, or any combination thereof, as our needs dictate. I estimate this allows us to expand by about 16,000 hosts distributed however we want, before running into problems where we have to rearrange subnets to accommodate growth. (That 16,000 number **includes VMs**.) 
 + 
 +  * Reservations (how it actually is right now, not how it should be. Infrastructure is painted into too small a corner.): 
 +    * 172.x.0.1 is always the external gateway for your location. 
 +    * 172.x.0.* and ranges immediately above it are for site infrastructure:​ switches, access points, cameras, printers, televisions,​ IoT and other spy devices... 
 +    * 172.x.1.* is casual DHCP. 
 +    * 172.x.{2..127}.* is for physical hosts and VMs homed to those hosts. The last octet gets divided up however that host's administrator chooses. 254 addresses for //​whatever//​. 
 +      * VMs homed to this specific host get IPs from this range. 
 +      * A host could also be a router or firewall with some kind of lab behind it. 
 +      * The lab might still want to be addressable from outside. 
 +      * IDK, let your imagination run wild. 
 +      * (My current plan: Reserve .1 for the interface you expect **always** to have connected. Reserve 1..63 for physical interfaces and 64..254 for homed VMs.) 
 +    * 172.x.{129..254}.* are for nomadic VMs. 
 + 
 +Nothing here is set in stone. If your installation calls for something else, the only restriction is that it has to be in the right IP space so access **could** be fully shared if we wanted it to be. (You should always consider the security implications of allowing connections from remote networks. Even from "​friendly"​ networks, you should probably start with "​reject all" and just add exceptions ​as you need them.) 
 +==== Security ==== 
 + 
 +Security happens in layers, and we implement those layers with network segments, by restricting the ways in which network can connect to each other. Not every location needs each kind of network. 
 + 
 +Here'​s ​first draft of the segments I'd like to implement. I know it's a lot, but much of it can be safely combined. You can get by with a "​guest"​ and "​trusted"​ network, and have all services deployed on a single physical host. This probably isn't ideal, but it's a good starting point and is very close to where we currently are. 
 + 
 +If you're not going to do anything that requires NFS (hahahaha) you can merge the Trusted and Guest networks. In 2019, we should be trying to get rid of such arrangements.  
 + 
 +=== Internet (I) === 
 +Just assume that everything here is out to kill you. I'm listing it here because technically it's a network segment, and I need to enumerate it in the connection policies. 
 + 
 +=== Internet + NAT (INAT) === 
 +Planned, controlled access from the Internet to an internal host via port forwarding. Think hard about security requirements before allowing access to something internal. 
 + 
 +=== Internet + Proxy (IP) === 
 +Reverse-proxying web traffic to a server inside the network. Unfortunately,​ traffic within the traffic must be HTTPSSL certificates will have to live on the server doing the proxying. 
 + 
 +=== Quarantine (Q) network === 
 +Systems that might behave in ways that disrupt normal network operations, such as send out bogus ARP traffic or DHCP leases. Outbound connections are allowed to the Internet. Inbound connections can be negotiated but are "drop by default"​. I only expect to need one of these at the fnord location. 
 + 
 +=== Guest (G) network=== 
 +Phones, tablets, laptops, casual users, people who are just vising. Things you offer to guests, like file shares (with access controls, of course) and printers. This is the WiFi password you give out to anyone you're willing to let into the house. (Or hackers park in front of the house for a few hours and sniff the password.) 
 + 
 +  * Allowed to connect to: (I,SN). NFS access is restricted to read-only filesystems for PXE purposes. 
 +  * Inbound connections from: (TW,TWC) 
 +  * Hosts **should** run their own firewall. 
 + 
 +=== Trusted Workstations (TW) network === 
 +Workstations and laptops that either live on-premises,​ or belong to trusted users. "​You'​re on your own" in terms of **local** VMs. Hosts and guests still have access to Horizon and the OpenStack API. There **should** be static leases and DNS entries for hosts, especially if they'​re going to host VMs locally (which also should have static leases if they'​re going to be fixtures). 
 + 
 +  * Outbound connections to: (I,​TWC,​SN) 
 +  * Inbound connections from: (I*,​TWC,​SN) 
 +  * Hosts and VMs **must** run their own firewall with a policy of dropping incoming connections by default. (I generally trust people on this. People who turn off their firewalls usually have good reasons for doing so.) 
 + 
 +=== Trusted Workstation Compute (TWC) network === 
 +Using a workstation as an OpenStack compute node is probably not something that's worth worrying about right now. The only differences between this network and the normal Trusted network would be: 
 + 
 +  * Outbound connections to: (I,TW,SN) 
 +  * Inbound connections from:  
 +  * Host would be **required** to be configured the same as any other OpenStack compute node, including Wake On LAN. 
 +  * Guests must use local storage (don't know how to do that yet) or PXE boot. 
 +  * Static leases for hosts **and guests** would be a hard requirement. 
 + 
 +Guests would be restricted to one host, and that host must only host those guests. Hosts **should** be configured to start their guests on boot and either pause, shutdown, or power them off as part of the host's shutdown sequence. 
 + 
 +=== Service Node (SN) === 
 +If a location is going to have just one host doing all the magic, this where it lives. If no dedicated firewall is used, this is the host that connects directly to the Internet and performs NAT and masquerading. **It needs to be running Shorewall unless someone else is going to manage the firewall**. 
 + 
 +  * Outbound connections:​ 
 +    * (I) on restricted ports (DNS, VPN, HTTP(S), maybe tightly controlled email, idk what else. Figure that out later.) 
 +  * Inbound connections:​ 
 +    * DNS (TCP **and** UDP) from 
 +    * HTTP(s) from * (keeping close track of what's accessible internally and externally) 
 +    * SSH on another port from * 
 +    * MySQL but only from (SN,CN,S) and grants need to be handled smartly. 
 +    * OpenStack client ports from (TW,​TWC,​Q,​CN) networks. 
 +    * NFS from (G,​TW,​TWC,​CN) 
 + 
 +The physical host needs to be running these services at a minimum: 
 +  * a web server of local admin'​s choice for proxying requests to VMs hosting websites (unless you have a firewall doing that for you) 
 +  * MySQL, but only for (SN,CN) 
 +  * NFS 
 +    * configure exports so the only thing the guest network can access is read-only PXE environments, ​and hosts in TWC and CN can access only access shares they should be able to access. 
 +    * maybe separate exports for the big/slow and small/fast array. 
 +  * Openstack 
 +    * Nova 
 +    * Keystone 
 +    * Glance 
 +    * Cinder 
 + 
 +=== Compute (CN) network === 
 +OpenStack compute nodes. 
 +  * Outbound connections to: 
 +    * (I,​TW,​TWC,​SN) (be really careful please) 
 +  * Inbound connections from: 
 +    * (IP,​INAT,​TW,​TWC,​SN) (be really careful please) 
 + 
 +One or more VMs need to run: 
 +  * Any websites / services intended for external consumption 
 +  * OpenStack Horizon 
 +  * Samba (?) 
 +  * MySQL for purposes other than OpenStack 
 +  * NextCloud 
 +  * SSH jump-off (jump-in?) guest with conveniences like OpenStack command-line tools and private user accounts 
 +  * PXE + TFTP. (Maybe a few of these, to provide different PXE environments more easily?) 
 + 
 +Remember: It's not as much as it sound like. It's a lot of VMs but each one is just doing one thing, and we'll get **massive** flexibility out of virtualizing. 
 + 
 +=== Storage (S) network === 
 +Big storage hosts that just export drives via ATA over Ethernet. Probably only for "big slow" since NVMe drives are faster than 10gigE and probably less expensive to build out. Might be a good "just for fun" project.  
 + 
 +  * Outbound connections to: 
 +    * (SN) for OS upgrades and to report problems 
 +  * Inbound connections from: 
 +    * (SN) for ATAoE 
 +===== Everything Below This Is Old ===== 
 + 
 +Learn how to do something. Do the thing. Document doing the thing. Automate doing the thing. Orchestrate the automation. **This is the documentation**.
  
 === Naptastic LAMP Stack ==== === Naptastic LAMP Stack ====
Line 17: Line 168:
     * PHP runs via Apache'​s mod_proxy_fcgi and PHP-FPM, which is amazing and my favorite PHP handler so far ever.     * PHP runs via Apache'​s mod_proxy_fcgi and PHP-FPM, which is amazing and my favorite PHP handler so far ever.
  
-=== Linux Pro Audio === +Probably the best thing to do here would be to throw this away and figure out something that doesn'​t require ​so many manual steps. I don't have time to recompile and install PHP on all my hosts every time there'​s a security update anymore.
-[[nndocs:​lad]] -- This is a long, long list of applications ​and plugins, ​so it should probably get split up at some point.+
  
-=== Have done, haven'​t documented ​=== +=== Linux Pro Audio === 
-[[nndocs:PXE]] -- Booting for network installations,​ diskless computers, or a common and easily-managed image+[[nndocs:lad]] -- Full-stack audio recording and production tools
-Custom kernel ​-- not sure if I really need or want to document this. There are so many great guides out there.+  * Built around the [[http://​jackaudio.org/​|JACK]] audio server, it provides anything-to-anywhere routing, networked operation, a wide variety of programs, broad hardware support, and extremely low-latency performance.
  
-know there'​s a lot more but I can't think of anything at the moment.+How much of this do really need anymore? Is it enough to just use Ubuntu Studio?
nndocs.1538174743.txt.gz · Last modified: 2018/09/28 22:45 by naptastic
 
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki