What You Need to Know Before Using This Wiki

Order Matters

The Order of Construction on the first page matters. Each step depends on the one before it.
If you skip any steps, make sure you review them for dependencies in later steps

Customizing the Network Model - Build your own Wiki

If you wish to use this as the starting point to build your own customized wiki.
Download File:COCNM-Wiki.xml, you will need to run several sed commands on it. Strings you will need to replace include:
"bob.miller" "Bob Miller" "computerisms.com" "DC=computerisms,DC=com" "dc=computerisms,dc=com" "192.168.26.10" "192.168.26.11" "192.168.26.1 ". Also:
all the passwords, and hostnames, and any subdomains, file names, or other naming conventions relating to your organization or aesthetics
Next install a wiki where ever suits you best, probably in a password protected environment. use Manual Importing to import the xml file
Go through and find the stuff that didn't work. Fix it till it works.
BIG FAT NOTE: As I use these instructions in my own day to day activities, I fix typos and mistakes as I find them and don't always update the XML file.
For a current XML file please mail me.

Plan Your Active Directory OUs Before You Begin

This wiki describes an Active Directory where all users are stored in the CN=Users container
LDAP authentication relies on users being at a certain place in the LDAP directory
authenticating services need to be configured to find users in that place
If you will put your users in custom OU structures, modify LDAP paths accordingly on this wiki

This is not a guide

As eloquently explained in a mailing list post I read some years ago, a guide must contain explanations, definitions and examples.
you won't find much of that here.
For the past decade, I have harvested data, techniques, skills, and other assorted information from the internet.
This is a condensed and refined interpretation of some of that information.
Here you will find a series of commands useful for building a sandbox network or for scripting server installations.
There is nothing here that I did not learn from Google and the Internet at Large, please look there for deeper understanding.

Corrections and Assistance

If on this site you find a mistake, a security risk, or a potential hazard, please do let me know and I will correct it.
If you wish to build a system like this one and require assistance, Computerisms provides Commercial Support
You are also welcome to subscribe to the mailing list cocnm@computerisms.ca

History and Purpose

I started using a wiki to document my learning in 2006.
I compiled notes. I got customers. I needed a quicker and more reliable way to replicate my install process
So I compiled the commands to build the individual services - copy/paste from wiki to terminal. I got bigger customers.
I needed a Unified Authentication system. I needed a new wiki. One wiki to rule the network.
Learned Samba4. Piped most of the stand alone services from the old wiki into the new one
This system (minus a few of the features) is stable in production for over 50 users. Tested as Working.
Rebuilt the sandbox environment from scratch and documented every step
Publishing this wiki is for two reasons:
1. So that those with the desire/skill to build a system like this might benefit from my learning, and
2. So those that need to hire the skills to build a system like this know I can do it.

The Real world

This wiki describes how to build a sandbox network. it is a model upon which to design a real-world network.
In the real world, you won't run your Asterisk server on your Domain Controller.
Nor would you have your CA on a network accessible computer.
This model is full of bad practise examples we shouldn't use in the real world.
As a template to a real-world network, this wiki is useful for planning and documentation
Decide the topology, system account, storage resource, and installations that will be used, and define this information on the front page for easy access
Keeping UIDs consistent across the network avoids any future conflicts with NFS, server migrations, and restoring backups
If you plan sufficiently, you can copy/paste just about everything into your terminal, but go slowly in case you miss something.
I don't think it is possible to build a system of this size without a few things going wrong. but keep your wiki in tune with what works, make notes where things deviate
At the end, when you have a working network, you also have an accurate history of how it was built, and a platform to build future upgrades on
Don't forget to lock your wiki away somehow so non-network administrators do not have access to it.

Disclaimer

This is a model meant to demonstrate how you can build a similar network. You use it at your own risk
It is assumed you bring a reasonable amount of linux administrative skills with you.
It is assumed you know what you need to change on this wiki to make it work for your environment
It is assumed that you understand what these instructions do before you use them.
There is no person who will be responsible for anything that happens if you choose to use these instructions except yourself, it is all on you.