howto/fabric.md

@@ -4,14 +4,14 @@ practices" for routine tasks like:
 
  * installing a server (TODO)
  * retiring a server ([howto/retire-a-host](howto/retire-a-host))
- * migrating machines ([howto/ganeti](howto/ganeti#Importing-external-instances))
+ * migrating machines ([service/ganeti](service/ganeti#Importing-external-instances))
  * retiring a user (TODO)
  * reboots ([howto/reboots](howto/reboots#Kernel-upgrades-and-reboots))
  * ... etc
 
 Fabric makes easy things reproducible and hard things possible. It is
 *not* designed to handle larger-scale configuration management, for
-which we use [howto/puppet](howto/puppet).
+which we use [service/puppet](service/puppet).
 
 [Invoke]: https://www.pyinvoke.org/
 [Fabric]: https://www.fabfile.org/
@@ -270,7 +270,7 @@ until adhoc shell scripts were written. But unfortunately now we have
 automating reboots as part of [ticket 33406](https://bugs.torproject.org/33406).
 
 And then it was time to migrate the second libvirt server to
-[howto/ganeti](howto/ganeti) (unifolium/kvm2, [ticket 33085](https://bugs.torproject.org/33085)) and by then it was
+[service/ganeti](service/ganeti) (unifolium/kvm2, [ticket 33085](https://bugs.torproject.org/33085)) and by then it was
 clear some more generic solution was required. An [attempt](https://gitlab.com/anarcat/tpa-ansible-libvirt-ganeti-importer) to
 implement this work in Ansible only led to frustration at the
 complexity of the task and tests were started on Fabric instead, which