1 | ============================================= |
---|
2 | Playbooks for administrating WAeUP servers. |
---|
3 | ============================================= |
---|
4 | |
---|
5 | These are materials to use with our servers. |
---|
6 | |
---|
7 | For starters: the tutorial given on |
---|
8 | |
---|
9 | https://github.com/leucos/ansible-tuto |
---|
10 | |
---|
11 | is a really nice hands-on intro to `ansible`. Please read it! |
---|
12 | |
---|
13 | If you want to devel/test scripts in here, try to work with virtual machines |
---|
14 | first. The ``Vagrant`` section below explains the details. |
---|
15 | |
---|
16 | Server Lifecircle |
---|
17 | ================= |
---|
18 | |
---|
19 | When we get a server freshly installed from Hetzner, we want to make sure, at |
---|
20 | least some common security holes are closed. |
---|
21 | |
---|
22 | |
---|
23 | Right after first install: `bootstrap.yml` |
---|
24 | ------------------------------------------ |
---|
25 | |
---|
26 | For starters we "bootstrap" a server install with the ``bootstrap.yml`` |
---|
27 | playbook. This playbook does three things: |
---|
28 | |
---|
29 | - It secures the ``SSHD`` config according to infos from |
---|
30 | https://bettercrypto.org |
---|
31 | - It adds accounts for admin users (including sudo rights) |
---|
32 | - It disables root login via SSH. |
---|
33 | |
---|
34 | Before the playbook can be run, you have to fix some things. |
---|
35 | |
---|
36 | 1) Make sure you can ssh into the systems as ``root``. |
---|
37 | |
---|
38 | 2) Make sure, Python2.x is installed on the target systems. This is not the |
---|
39 | case anymore for instance for minimal Ubuntu images starting with 16.04 LTS. |
---|
40 | |
---|
41 | If Python2.x is not installed, do:: |
---|
42 | |
---|
43 | # apt-get update |
---|
44 | # apt-get install python python-simplejson |
---|
45 | |
---|
46 | as `root` on each targeted system. |
---|
47 | |
---|
48 | |
---|
49 | 3) For each server to handle, make an entry in the ``[yet-untouched]`` section |
---|
50 | of the ``hosts`` file like this:: |
---|
51 | |
---|
52 | # hosts |
---|
53 | [yet-untouched] |
---|
54 | h23.waeup.org ansible_user=root ansible_ssh_pass=so-secret ansible_sudo_pass="{{ ansible_ssh_pass }}" |
---|
55 | h24.waeup.org ansible_user=root ansible_ssh_pass=123456789 ansible_sudo_pass="{{ ansible_ssh_pass }}" |
---|
56 | |
---|
57 | The ``ansible_sudo_pass`` is not neccessary for now, but will be needed if |
---|
58 | you want to run everything as a normal user. And it is just a blank copy of |
---|
59 | ``ansible_ssh_pass``. |
---|
60 | |
---|
61 | Yes, this is a very dangerous part and you should not check this |
---|
62 | modifications in. Instead you should remove the entries after you are done. |
---|
63 | |
---|
64 | 4) Update the ``vars`` in ``bootstrap.yml``. Tell, whether SSH root access |
---|
65 | should stay enabled and say ``no`` or ``false``. |
---|
66 | |
---|
67 | Then, you have to create a dict of admin users. For each user we need a name |
---|
68 | (key) and a hashed password. This can be done like this:: |
---|
69 | |
---|
70 | $ diceware -d '-' -n 6 --no-caps | tee mypw | mkpasswd -s --method=sha-512 >> mypw |
---|
71 | |
---|
72 | which will create a random password and its SHA512-hashed variant in a file |
---|
73 | called ``mypw``. If you do not have `diceware` installed, you can use |
---|
74 | `pwgen` (or any other password maker):: |
---|
75 | |
---|
76 | $ pwgen -s 33 | tee mypw | mkpasswd -s --method=sha-512 >> mypw |
---|
77 | |
---|
78 | The hashed variant then has to be entered as ``hashed_pw`` in the `vars` of |
---|
79 | ``bootstrap.yml``. |
---|
80 | |
---|
81 | In the end, there should be something like:: |
---|
82 | |
---|
83 | # bootstrap.yml |
---|
84 | # ... |
---|
85 | vars: |
---|
86 | permit_ssh_root: false |
---|
87 | admin_users: |
---|
88 | user1: |
---|
89 | hashed_pw: "$6$Wsdfhwelkl32lslk32lkdslk43...." |
---|
90 | user2: |
---|
91 | hashed_pw: "$6$FDwlkjewlkWs2434SVRDE65DFF...." |
---|
92 | ... |
---|
93 | |
---|
94 | Please note, that all users listed in this dict will have the same passwords |
---|
95 | on all servers handled when running the script. |
---|
96 | |
---|
97 | 5) Finally, run the play:: |
---|
98 | |
---|
99 | $ ansible-playbook -i hosts -C bootstrap.yml |
---|
100 | |
---|
101 | to see, whether setup is fine (dry run) and:: |
---|
102 | |
---|
103 | $ ansible-playbooj -i hosts bootstrap.yml |
---|
104 | |
---|
105 | to actually perform the changes. |
---|
106 | |
---|
107 | |
---|
108 | Vagrant |
---|
109 | ======= |
---|
110 | |
---|
111 | In `Vagrantfile` we set up a vagrant environment which provides three |
---|
112 | hosts as virtualbox: |
---|
113 | |
---|
114 | ``vh5.sample.org``, ``vh6.sample.org``, ``vh7.sample.org`` |
---|
115 | |
---|
116 | running Ubuntu 14.04. ``vh5`` represents "virtual host 5" and should |
---|
117 | reflect h5.waeup.org. The same holds for ``vh6`` and ``vh7`` |
---|
118 | accordingly. |
---|
119 | |
---|
120 | The three virtual hosts are for testing any upcoming ansible |
---|
121 | playbooks. They should be used before running playbooks on the real |
---|
122 | hosts! |
---|
123 | |
---|
124 | |
---|
125 | Initialize Vagrant Env |
---|
126 | ---------------------- |
---|
127 | |
---|
128 | You must have `vagrant` installed, if possible in a fairly recent |
---|
129 | version. I (uli) use `vagrant 1.8.1` (latest as time of writing). As |
---|
130 | Ubuntu 14.04 is pretty outdated in that respect, I had to grab a .deb |
---|
131 | package from |
---|
132 | |
---|
133 | https://www.vagrantup.com/downloads.html |
---|
134 | |
---|
135 | that could be installed with:: |
---|
136 | |
---|
137 | $ sudo dpkg -i vagrant_1.8.1_x86_64.deb |
---|
138 | |
---|
139 | |
---|
140 | When everything is in place, change into this directory and run:: |
---|
141 | |
---|
142 | $ vagrant up |
---|
143 | Bringing machine 'vh5' up with 'virtualbox' provider... |
---|
144 | Bringing machine 'vh6' up with 'virtualbox' provider... |
---|
145 | Bringing machine 'vh7' up with 'virtualbox' provider... |
---|
146 | ==> vh5: Importing base box 'ubuntu/trusty32'... |
---|
147 | ... |
---|
148 | |
---|
149 | This will fetch Vagrant virtualbox images for trusty32, i.e. Ubuntu |
---|
150 | 14.04 images, 32bit version (plays nice also on 64bit hosts). |
---|
151 | |
---|
152 | When hosts are being supplied by Hetzner or another hosting provider, |
---|
153 | then we normally get access as `root` user only. Therefore, After base |
---|
154 | init the root accounts of all hosts are enabled with password |
---|
155 | ``vagrant``. This is done by the ansible playbook in |
---|
156 | ``vagrant-provision.yml``. |
---|
157 | |
---|
158 | All three hosts provide ssh access via:: |
---|
159 | |
---|
160 | $ vagrant ssh vh0 |
---|
161 | |
---|
162 | or equivalent commands. They have a user 'vagrant' installed, which |
---|
163 | can sudo without password. |
---|
164 | |
---|
165 | After install all three hosts can also be accessed as `root` using |
---|
166 | password `vagrant` (for example vh5): |
---|
167 | |
---|
168 | $ ssh -l root 192.168.36.10 |
---|
169 | |
---|
170 | See ``Vagrantfile`` for the IP addresses set. |
---|
171 | |
---|
172 | You can halt (all) the virtual hosts with:: |
---|
173 | |
---|
174 | $ vagrant halt |
---|
175 | |
---|
176 | |
---|
177 | |
---|
178 | Ansible Environment |
---|
179 | =================== |
---|
180 | |
---|
181 | The ansible environment should provide ansible roles and playbooks for |
---|
182 | WAeUP related server administration. |
---|
183 | |
---|
184 | The general file-layout and naming should follow |
---|
185 | |
---|
186 | https://docs.ansible.com/ansible/playbooks_best_practices.html#directory-layout |
---|
187 | |
---|
188 | |
---|
189 | Bootstrapping - Freshmechs |
---|
190 | -------------------------- |
---|
191 | |
---|
192 | We call those machines "freshmech" that are freshly delivered from the |
---|
193 | hosting provider or that were freshly provisioned by `vagrant` (see |
---|
194 | above). |
---|
195 | |
---|
196 | These machines are expected to have only a single root account and |
---|
197 | normally a (security-wise) poor SSH configuration. |
---|
198 | |
---|
199 | Bootstrapping these machines means we secure SSH, restart the SSH |
---|
200 | daemon and then add important accounts: "uli", "henrik", "ansible". |
---|
201 | |
---|
202 | To make sure, the connection to a "freshmech" works, you should at |
---|
203 | least one time login via SSH before proceeding with ansible and all |
---|
204 | bells and whistles:: |
---|
205 | |
---|
206 | ssh -l root 192.168.36.10 |
---|
207 | |
---|
208 | (with the real IP of the machine you want to reach, of course). |
---|
209 | |
---|
210 | Any host you want to "bootstrap" must be entered in a local hosts |
---|
211 | file, normally ``hosts-virtual``, with a line like this: |
---|
212 | |
---|
213 | [yet-untouched] |
---|
214 | vh5.sample.org ansible_host=192.168.36.10 ansible_user=root |
---|
215 | |
---|
216 | in the "yet-untouched" section. |
---|
217 | |
---|
218 | Afterwards try: |
---|
219 | |
---|
220 | $ ansible-playbook -i hosts-virtual --ask-pass bootstrap.yml |
---|
221 | |
---|
222 | The ``ask-pass`` parameter is needed to enter the password given by |
---|
223 | the provider on the commandline. For the local `vagrant` machines this |
---|
224 | will be `vagrant`. |
---|
225 | |
---|
226 | If run on local virtual machines, you might want to make sure that |
---|
227 | your local `known_hosts` file does not contain an old ssh host |
---|
228 | fingerprint. Otherwise you have to remove entries for:: |
---|
229 | |
---|
230 | 192.168.36.10 |
---|
231 | 192.168.36.11 |
---|
232 | 192.168.36.12 |
---|
233 | |
---|
234 | respectively before running `bootstrap.yml`. |
---|
235 | |
---|
236 | Alternatively you can run everything with the |
---|
237 | `ANSIBLE_HOST_KEY_CHECKING` environment variable set to ``False``:: |
---|
238 | |
---|
239 | $ ANSIBLE_HOST_KEY_CHECKING=False ansible-playbook -i hosts-virtual --ask-pass bootstrap.yml |
---|
240 | |
---|
241 | This will suppress host fingerprint checking. |
---|