DuckCorp » DuckCorp Infrastructure

LGTM. I'll let you merge when ready for the switch.

Don't forget to change the sup-poller.duckcorp.org and sup.duckcorp.org CNAMEs in the DNS when switching.

Also let's try to move the old database too. It should be a matter of copying files since the database version will be the same.

Marc Dequènes wrote:

LGTM. I'll let you merge when ready for the switch.

I plan to deploy, fix and merge :)

Don't forget to change the sup-poller.duckcorp.org and sup.duckcorp.org CNAMEs in the DNS when switching.

Done (applied with: systemctl reload bind9.service):

--- /etc/bind/masters/duckcorp.org.zone.ori    2020-07-08 14:55:54.000000000 +0200
+++ /etc/bind/masters/duckcorp.org.zone    2020-07-08 14:56:38.000000000 +0200
@@ -1,7 +1,7 @@
 $TTL 600
 $ORIGIN    .
 duckcorp.org        IN SOA    ns1.duckcorp.org.    hostmaster.duckcorp.org. (
-                37 ; serial
+                38 ; serial
                 3600 ; refresh
                 3600 ; retry
                 3600000 ; expire
@@ -169,7 +169,7 @@
 _ntp._tcp        IN SRV        0 0    123    orfeo
 hurd            IN CNAME    earendil.hq
 dict            IN CNAME    jinta
-sup-poller        IN CNAME    nicecity
+sup-poller        IN CNAME    orthos
 sup-proxy-1        IN CNAME    elwing.hq

 ; used to make CNAME entries in external domains
@@ -210,7 +210,7 @@
 ; Web vhosts (Thorfinn)
 static.perso        IN CNAME        thorfinn
 ; Web vhosts (Nicecity)
-sup            IN CNAME    nicecity
+sup            IN CNAME    orthos

 ; Aliases
 home            IN CNAME    elwing

$ journalctl -u bind9.service
[...]
Jul 08 14:57:52 Orfeo systemd[1]: Reloaded BIND Domain Name Server.
Jul 08 14:57:52 Orfeo named[29397]: all zones loaded
Jul 08 14:57:52 Orfeo named[29397]: running
[...]
Jul 08 14:57:52 Orfeo named[29397]: zone duckcorp.org/IN (unsigned): loaded serial 38
Jul 08 14:57:52 Orfeo named[29397]: zone duckcorp.org/IN (signed): serial 685 (unsigned 38)

The following patch have been applied on Orthos:

--- /etc/hosts.ori    2020-07-08 10:10:18.119404618 -0400
+++ /etc/hosts    2020-07-08 10:10:36.490712268 -0400
@@ -1,5 +1,5 @@
 127.0.0.1    localhost
-127.0.1.1    ibm-p8-kvm-03-guest-02.virt.pnr.lab.eng.rdu2.redhat.com    orthos.duckcorp.org
+127.0.1.1    orthos.duckcorp.org orthos

 # The following lines are desirable for IPv6 capable hosts
 ::1     localhost ip6-localhost ip6-loopback

Branch duckcorp-infra@move_sup_server has been updated:

diff --git a/ansible/roles/dc-base/templates/fw/Orthos b/ansible/roles/dc-base/templates/fw/Orthos
index c777ee0..b70d99b 100644
--- a/ansible/roles/dc-base/templates/fw/Orthos
+++ b/ansible/roles/dc-base/templates/fw/Orthos
@@ -4,7 +4,7 @@ NFLOG_GROUP=1

 # Services available on all interfaces, IPv4/IPv6
 declare -A ALL=(
-  ["SRV_TCP"]="ssh" 
+  ["SRV_TCP"]="ssh zabbix-trapper http https" 
   ["SRV_UDP"]="" 
 )

diff --git a/ansible/roles/dc-base/templates/fw/Nicecity b/ansible/roles/dc-base/templates/fw/Nicecity
index 1bda35a..e49fe6f 100644
--- a/ansible/roles/dc-base/templates/fw/Nicecity
+++ b/ansible/roles/dc-base/templates/fw/Nicecity
@@ -5,7 +5,7 @@ BACKUP="4971:4972" 

 # Services available on all interfaces, IPv4/IPv6
 declare -A ALL=(
-  ["SRV_TCP"]="ssh zabbix-trapper http https ${BACKUP}" 
+  ["SRV_TCP"]="ssh ${BACKUP}" 
   ["SRV_UDP"]="" 
 )

Deployed using the following command and the patches #705, #706, #707:

ansible-playbook --check -vv --diff playbooks/dc.yml -l Orthos

Nicecity zabbix database has been imported:

postgres@orthos:~$ systemctl stop zabbix-server.service
postgres@nicecity:~$ pg_dump -f zabbix.dump -d zabbix -v --clean --create
postgres@orthos:~$ psql -f zabbix.dump
postgres@orthos:~$ systemctl start zabbix-server.service

Redeploy in order to register Orthos zabbix agent:

ansible-playbook --check -vv --diff playbooks/dc.yml -l Orthos --tags monitoring

Orthos is now allowed to use 2 vcpu, the virtual machine has been restarted in order to take this update in account.

Well done, it works fine and old data are there. I merged the branch.

I think we should generate /etc/hosts or at least ensure certain entries like 127.0.1.1 are fine. If you agree then let's create a new ticket.

When the firewalling issue is fixed then we can consider this task done.

Marc Dequènes wrote:

I think we should generate /etc/hosts or at least ensure certain entries like 127.0.1.1 are fine. If you agree then let's create a new ticket.

I agree.

When the firewalling issue is fixed then we can consider this task done.

Issue fixed :)