{"id":36601,"date":"2025-01-17T07:08:16","date_gmt":"2025-01-17T06:08:16","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/?p=36601"},"modified":"2025-01-20T12:54:33","modified_gmt":"2025-01-20T11:54:33","slug":"creating-your-private-cloud-using-openstack-2-preparing-the-nodes","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/creating-your-private-cloud-using-openstack-2-preparing-the-nodes\/","title":{"rendered":"Creating your private cloud using OpenStack \u2013 (2) \u2013 Preparing the nodes"},"content":{"rendered":"\n

In the introduction post <\/a>we’ve briefly looked at some options you have available when you want to build your own private cloud. In this post we’re going to start our journey into OpenStack by preparing the two nodes we’re going to use for this setup: The controller node, and one compute node. Maybe you remember from the last post, this is our starting point:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

A minimal installation of Rocky Linux 9 is straight forward, so we’re not going to look into this. Once both machines are installed it should look more or less like this (I am using KVM and virt-manager<\/a> in my setup which auto assigns IP addresses by default):<\/p>\n\n\n

\n###### CONTROLLER NODE\n[root@controller ~]$ ip a\n1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000\n    link\/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00\n    inet 127.0.0.1\/8 scope host lo\n       valid_lft forever preferred_lft forever\n    inet6 ::1\/128 scope host \n       valid_lft forever preferred_lft forever\n2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000\n    link\/ether 52:54:00:38:00:73 brd ff:ff:ff:ff:ff:ff\n    inet 192.168.122.19\/24 brd 192.168.122.255 scope global dynamic noprefixroute enp1s0\n       valid_lft 3565sec preferred_lft 3565sec\n    inet6 fe80::5054:ff:fe38:73\/64 scope link noprefixroute \n       valid_lft forever preferred_lft forever\n3: enp7s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000\n    link\/ether 52:54:00:81:1d:26 brd ff:ff:ff:ff:ff:ff\n    inet 10.0.0.233\/24 brd 10.0.0.255 scope global dynamic noprefixroute enp7s0\n       valid_lft 3565sec preferred_lft 3565sec\n    inet6 fe80::9f14:4737:4cf7:d88f\/64 scope link noprefixroute \n       valid_lft forever preferred_lft forever\n\n###### COMPUTE NODE\n[root@compute ~]$ ip a\n1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000\n    link\/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00\n    inet 127.0.0.1\/8 scope host lo\n       valid_lft forever preferred_lft forever\n    inet6 ::1\/128 scope host \n       valid_lft forever preferred_lft forever\n2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000\n    link\/ether 52:54:00:b8:8e:c0 brd ff:ff:ff:ff:ff:ff\n    inet 192.168.122.138\/24 brd 192.168.122.255 scope global dynamic noprefixroute enp1s0\n       valid_lft 3376sec preferred_lft 3376sec\n    inet6 fe80::5054:ff:feb8:8ec0\/64 scope link noprefixroute \n       valid_lft forever preferred_lft forever\n3: enp7s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000\n    link\/ether 52:54:00:7c:27:a4 brd ff:ff:ff:ff:ff:ff\n    inet 10.0.0.254\/24 brd 10.0.0.255 scope global dynamic noprefixroute enp7s0\n       valid_lft 3378sec preferred_lft 3378sec\n    inet6 fe80::7981:d103:c103:2804\/64 scope link noprefixroute \n       valid_lft forever preferred_lft forever\n<\/pre><\/div>\n\n\n
As you can see, there are two networks. The configuration for both is:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n
This is the reason, both interfaces already got IP addresses. In an OpenStack setup, you don’t want to have this and should go for a static configuration of the nodes. While the first interface on the nodes must be configured and must be able to reach the internet, the second interface should not connect to any network be default. To achieve this, a manual configuration of the interfaces is required. Here are the steps to do that on the controller node:<\/p>\n\n\n
\n[root@controller ~]$ nmcli con show\nNAME                UUID                                  TYPE      DEVICE \nenp1s0              5ef7a54f-8219-3287-8030-572251acfb7e  ethernet  enp1s0 \nWired connection 1  733abc24-3c2d-3e17-a37e-8ae1e19d58a5  ethernet  enp7s0 \nlo                  bf801f94-99ea-40d9-b7c4-dc89930a42f5  loopback  lo     \n[root@controller ~]$ nmcli con mod "enp1s0" \\\n  ipv4.addresses "192.168.122.90\/24" \\\n  ipv4.gateway "192.168.122.1" \\\n  ipv4.dns "192.168.122.1,8.8.8.8" \\\n  ipv4.dns-search "it.dbi-services.com" \\\n  ipv4.method "manual"\n[root@controller ~]$ nmcli con down enp1s0\n[root@controller ~]$ nmcli up down enp1s0\n[root@controller ~]$ ip a\n1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000\n    link\/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00\n    inet 127.0.0.1\/8 scope host lo\n       valid_lft forever preferred_lft forever\n    inet6 ::1\/128 scope host \n       valid_lft forever preferred_lft forever\n2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000\n    link\/ether 52:54:00:38:00:73 brd ff:ff:ff:ff:ff:ff\n    inet 192.168.122.90\/24 brd 192.168.122.255 scope global noprefixroute enp1s0\n       valid_lft forever preferred_lft forever\n    inet6 fe80::5054:ff:fe38:73\/64 scope link noprefixroute \n       valid_lft forever preferred_lft forever\n3: enp7s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000\n    link\/ether 52:54:00:81:1d:26 brd ff:ff:ff:ff:ff:ff\n    inet 10.0.0.233\/24 brd 10.0.0.255 scope global dynamic noprefixroute enp7s0\n       valid_lft 2753sec preferred_lft 2753sec\n    inet6 fe80::9f14:4737:4cf7:d88f\/64 scope link noprefixroute \n       valid_lft forever preferred_lft forever\n\n[root@controller ~]$ nmcli conn modify "Wired connection 1" con-name "enp7s0"\n[root@controller ~]$ nmcli conn show\nNAME    UUID                                  TYPE      DEVICE \nenp7s0  733abc24-3c2d-3e17-a37e-8ae1e19d58a5  ethernet  enp7s0 \nenp1s0  5ef7a54f-8219-3287-8030-572251acfb7e  ethernet  enp1s0 \nlo      bf801f94-99ea-40d9-b7c4-dc89930a42f5  loopback  lo  \n\n[root@controller ~]$ nmcli con modify enp7s0 +ipv4.routes "10.0.0.0\/24 10.0.10.1" ipv4.method "manual"\n[root@controller ~]$ nmcli con down enp7s0\n[root@controller ~]$ nmcli con up enp7s0\n[root@controller ~]$ ip a\n1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000\n    link\/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00\n    inet 127.0.0.1\/8 scope host lo\n       valid_lft forever preferred_lft forever\n    inet6 ::1\/128 scope host \n       valid_lft forever preferred_lft forever\n2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000\n    link\/ether 52:54:00:38:00:73 brd ff:ff:ff:ff:ff:ff\n    inet 192.168.122.90\/24 brd 192.168.122.255 scope global noprefixroute enp1s0\n       valid_lft forever preferred_lft forever\n    inet6 fe80::5054:ff:fe38:73\/64 scope link noprefixroute \n       valid_lft forever preferred_lft forever\n3: enp7s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000\n    link\/ether 52:54:00:81:1d:26 brd ff:ff:ff:ff:ff:ff\n    inet6 fe80::9f14:4737:4cf7:d88f\/64 scope link noprefixroute \n       valid_lft forever preferred_lft forever\n<\/pre><\/div>\n\n\n
The explanation of what happened: We’ve configured the first interface (enp1s0) to use a static configuration, providing the IP address, the gateway and the DNS servers we want to use. To activate the settings, we took that connection down and up again (depending on how you are connected at this step, you might lose your connection, so be careful). We’ve then renamed the second connection from “Wired connection 1” to use the name of the second interface to be consistent with the first connection. Finally we switched the “enp7s0” connection from an automatically assigned to statically assigned configuration, but we did not specify an IP address.<\/p>\n\n\n\n
Once you followed the same steps for the compute node (using another IP address for the enp1s0 interface, of course), you should have something like this:<\/p>\n\n\n
\n[root@compute ~]$ ip a\n1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000\n    link\/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00\n    inet 127.0.0.1\/8 scope host lo\n       valid_lft forever preferred_lft forever\n    inet6 ::1\/128 scope host \n       valid_lft forever preferred_lft forever\n2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000\n    link\/ether 52:54:00:b8:8e:c0 brd ff:ff:ff:ff:ff:ff\n    inet 192.168.122.91\/24 brd 192.168.122.255 scope global noprefixroute enp1s0\n       valid_lft forever preferred_lft forever\n    inet6 fe80::5054:ff:feb8:8ec0\/64 scope link noprefixroute \n       valid_lft forever preferred_lft forever\n3: enp7s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000\n    link\/ether 52:54:00:7c:27:a4 brd ff:ff:ff:ff:ff:ff\n    inet6 fe80::7981:d103:c103:2804\/64 scope link noprefixroute \n       valid_lft forever preferred_lft forever\n<\/pre><\/div>\n\n\n
So, now we are exactly here:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Btw: If you are still used to find your network interface configuration under “\/etc\/sysconfig\/network-scripts\/” on Red Hat based distributions you’ll be surprised, there isn’t anything anymore:<\/p>\n\n\n
\n[root@controller ~]$ ls \/etc\/sysconfig\/network-scripts\/\nreadme-ifcfg-rh.txt\n<\/pre><\/div>\n\n\n
Configurations for NetworkManager are here:<\/p>\n\n\n
\n[root@controller ~]$ ls -la \/etc\/NetworkManager\/system-connections\/\ntotal 8\ndrwxr-xr-x. 2 root root  60 Jan 16 14:15 .\ndrwxr-xr-x. 7 root root 134 Jan 16 13:43 ..\n-rw-------. 1 root root 331 Jan 16 14:02 enp1s0.nmconnection\n-rw-------. 1 root root 262 Jan 16 14:15 enp7s0.nmconnection\n<\/pre><\/div>\n\n\n
These are still plain text files, but in INI<\/a> format:<\/p>\n\n\n
\n[root@controller ~]$ cat \/etc\/NetworkManager\/system-connections\/enp1s0.nmconnection \n[connection]\nid=enp1s0\nuuid=5ef7a54f-8219-3287-8030-572251acfb7e\ntype=ethernet\nautoconnect-priority=-999\ninterface-name=enp1s0\ntimestamp=1737031847\n\n[ethernet]\n\n[ipv4]\naddress1=192.168.122.90\/24,192.168.122.1\ndns=192.168.122.1;8.8.8.8;\ndns-search=it.dbi-services.com;\nmethod=manual\n\n[ipv6]\naddr-gen-mode=eui64\nmethod=auto\n\n[proxy]\n<\/pre><\/div>\n\n\n
Another requirement before we can start to deploy OpenStack services is name resolution. In this demo setup we’re just using the hosts<\/a> file for this as we do not have a DNS service available. This looks the same for both nodes:<\/p>\n\n\n
\n[root@controller ~]$ cat \/etc\/hosts\n127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4\n::1         localhost localhost.localdomain localhost6 localhost6.localdomain6\n\n192.168.122.90 controller controller.it.dbi-services.com\n192.168.122.91 compute compute.it.dbi-services.com\n\n[root@controller ~]$ ping -c1 controller\nPING controller (192.168.122.90) 56(84) bytes of data.\n64 bytes from controller (192.168.122.90): icmp_seq=1 ttl=64 time=0.061 ms\n\n--- controller ping statistics ---\n1 packets transmitted, 1 received, 0% packet loss, time 0ms\nrtt min\/avg\/max\/mdev = 0.061\/0.061\/0.061\/0.000 ms\n[root@controller ~]$ ping -c1 compute\nPING compute (192.168.122.91) 56(84) bytes of data.\n64 bytes from compute (192.168.122.91): icmp_seq=1 ttl=64 time=1.05 ms\n\n--- compute ping statistics ---\n1 packets transmitted, 1 received, 0% packet loss, time 0ms\nrtt min\/avg\/max\/mdev = 1.049\/1.049\/1.049\/0.000 ms\n<\/pre><\/div>\n\n\n
Time synchronization is another bit to get right. What we do here is to let the controller node synchronize the time from the internet and let the compute node synchronize its time from the controller node. To configure the controller node to synchronize from the internet there is nothing to do, but we need to allow other nodes in the same subnet to synchronize from the controller node:<\/p>\n\n\n
\n# keep everything as it is, but allow nodes from the same subnet to synchronize from this node\n[root@controller ~]$ grep allow \/etc\/chrony.conf\nallow 192.168.122.0\/24\n[root@controller ~]$ systemctl restart chronyd\n<\/pre><\/div>\n\n\n
Configure the compute node to synchronize from the controller node:<\/p>\n\n\n
\n# keep everything as it is, but comment out the pool and specify the controller node as the server\n[root@compute ~]$ grep -B 1 -w server \/etc\/chrony.conf \n#pool 2.rocky.pool.ntp.org iburst\nserver controller iburst\n[root@compute ~]$ systemctl restart chronyd\n<\/pre><\/div>\n\n\n
To verify that everything is working as expected, check the chrony<\/a> sources on the compute node:<\/p>\n\n\n
\n[root@compute ~]$ chronyc sources\nMS Name\/IP address         Stratum Poll Reach LastRx Last sample               \n===============================================================================\n^? controller                    0   7     0     -     +0ns[   +0ns] +\/-    0ns\n<\/pre><\/div>\n\n\n
As we will install the OpenStack services from packages later on, we need to make sure that we have the required repositories<\/a> enabled on both<\/strong> of the nodes:<\/p>\n\n\n
\n[root@controller ~]$ dnf config-manager --set-enabled baseos    # should be enabled by default\n[root@controller ~]$ dnf config-manager --set-enabled appstream # should be enabled by default\n[root@controller ~]$ dnf config-manager --set-enabled crb\n<\/pre><\/div>\n\n\n
Having that ready, we can use the repository provided by the RDO project<\/a>, to install the OpenStack client:<\/p>\n\n\n
\n[root@controller ~]$ dnf install http:\/\/trunk.rdoproject.org\/rdo_release\/rdo-release.el9s.rpm -y\n[root@controller ~]$ dnf upgrade -y\n[root@controller ~]$ dnf install python3-openstackclient openstack-selinux -y\n<\/pre><\/div>\n\n\n
The final step for preparing the nodes is to install a SQL database engine on the controller node<\/strong>. The reason is, that several OpenStack services require a database to store their configurations (more on that later). There are several supported engines, but we’ll go with PostgreSQL for obvious reasons (just in case you ask yourself why this is obvious, check this blog for PostgreSQL related blog posts \ud83d\ude42 ). In a production setup you wouldn’t install the database on the controller node, but externalize it, make it high available and put in place proper backup and restore processes. For the scope of this blog series, we don’t care and will go with an unprotected single instance of PostgreSQL.<\/p>\n\n\n\n
Red Hat Enterprise Linux 9 based distributions come with a packaged version of PostgreSQL by default:<\/p>\n\n\n
\n[root@controller ~]$ dnf search postgresql-server\nLast metadata expiration check: 0:05:54 ago on Thu 16 Jan 2025 03:18:44 PM CET.\n========================================= Name Exactly Matched: postgresql-server ==========================================\npostgresql-server.x86_64 : The programs needed to create and run a PostgreSQL server\n============================================= Name Matched: postgresql-server ==============================================\npostgresql-server-devel.x86_64 : PostgreSQL development header files and libraries\n<\/pre><\/div>\n\n\n
Please do not<\/strong> use this one, as this is PostgreSQL 13 which will go out of support<\/a> this November:<\/p>\n\n\n
\n[root@controller ~]$ dnf info postgresql-server | grep Version\nVersion      : 13.18\n<\/pre><\/div>\n\n\n
If you want to go for a packaged version from Red Hat, at least use the latest one you can find in the AppStream<\/a> repository:<\/p>\n\n\n
\n[root@controller ~]$ dnf module list\nLast metadata expiration check: 0:08:44 ago on Thu 16 Jan 2025 03:18:44 PM CET.\nRocky Linux 9 - AppStream\nName        Stream Profiles                              Summary                                                            \nmariadb     10.11  client, galera, server [d]            MariaDB Module                                                     \nmaven       3.8    common [d]                            Java project management and project comprehension tool             \nnginx       1.22   common [d]                            nginx webserver                                                    \nnginx       1.24   common [d]                            nginx webserver                                                    \nnodejs      18     common [d], development, minimal, s2i Javascript runtime                                                 \nnodejs      20     common [d], development, minimal, s2i Javascript runtime                                                 \nnodejs      22     common [d], development, minimal, s2i Javascript runtime                                                 \nphp         8.1    common [d], devel, minimal            PHP scripting language                                             \nphp         8.2    common [d], devel, minimal            PHP scripting language                                             \npostgresql  15     client, server [d]                    PostgreSQL server and client module                                \npostgresql  16     client, server [d]                    PostgreSQL server and client module                                \nredis       7      common [d]                            Redis persistent key-value database                                \nruby        3.1    common [d]                            An interpreter of object-oriented scripting language               \nruby        3.3    common [d]                            An interpreter of object-oriented scripting language               \n\nRocky Linux 9 - CRB\nName        Stream Profiles                              Summary                                                            \nswig        4.1    common [d], complete                  Connects C\/C++\/Objective C to some high-level programming languages\n\nHint: [d]efault, [e]nabled, [x]disabled, [i]nstalled\n<\/pre><\/div>\n\n\n
In this case, please go with version 16:<\/p>\n\n\n
\n[root@controller ~]$ dnf module enable postgresql:16 -y\n[root@controller ~]$ dnf install postgresql-server -y\n<\/pre><\/div>\n\n\n
An even better approach is to install PostgreSQL from the community provided repositories<\/a>.<\/p>\n\n\n\n
Before the OpenStack services can use PostgreSQL, there needs to be a running instance, so lets create this:<\/p>\n\n\n
\n[root@controller ~]$ \/usr\/bin\/postgresql-setup --initdb\n * Initializing database in '\/var\/lib\/pgsql\/data'\n * Initialized, logs are in \/var\/lib\/pgsql\/initdb_postgresql.log\n[root@controller ~]$ systemctl enable postgresql\n[root@controller ~]$ systemctl start postgresql\n[root@controller ~]$ su - postgres -c "psql -c 'select version()'"\n                                                   version                                                    \n--------------------------------------------------------------------------------------------------------------\n PostgreSQL 16.6 on x86_64-redhat-linux-gnu, compiled by gcc (GCC) 11.5.0 20240719 (Red Hat 11.5.0-2), 64-bit\n(1 row)\n<\/pre><\/div>\n\n\n
The Red Hat package configures PostgreSQL for “ident<\/a>” authentication by default:<\/p>\n\n\n
\n[root@controller ~]$ cat \/var\/lib\/pgsql\/data\/pg_hba.conf | egrep -v "^#|^$"\nlocal   all             all                                     peer\nhost    all             all             127.0.0.1\/32            ident\nhost    all             all             ::1\/128                 ident\nlocal   replication     all                                     peer\nhost    replication     all             127.0.0.1\/32            ident\nhost    replication     all             ::1\/128                 ident\n<\/pre><\/div>\n\n\n
This is probably not what you want, so lets switch this to “scram-sha-256<\/a>” and in addition we want to allow connections from the same subnet:<\/p>\n\n\n
\n[root@controller ~]$ sed -i 's\/ident\/scram-sha-256\/g' \/var\/lib\/pgsql\/data\/pg_hba.conf\n[root@controller ~]$ echo "host    all             all             192.168.122.0\/24           scram-sha-256" >> \/var\/lib\/pgsql\/data\/pg_hba.conf \n[root@controller ~]$ systemctl reload postgresql\n[root@controller ~]# su - postgres -c "psql -c 'select * from pg_hba_file_rules'"\n rule_number |            file_name            | line_number | type  |   database    | user_name |    address    |                 netmask                 |  auth_method  | options | error \n-------------+---------------------------------+-------------+-------+---------------+-----------+---------------+-----------------------------------------+---------------+---------+-------\n           1 | \/var\/lib\/pgsql\/data\/pg_hba.conf |         113 | local | {all}         | {all}     |               |                                         | peer          |         | \n           2 | \/var\/lib\/pgsql\/data\/pg_hba.conf |         115 | host  | {all}         | {all}     | 127.0.0.1     | 255.255.255.255                         | scram-sha-256 |         | \n           3 | \/var\/lib\/pgsql\/data\/pg_hba.conf |         117 | host  | {all}         | {all}     | ::1           | ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff | scram-sha-256 |         | \n           4 | \/var\/lib\/pgsql\/data\/pg_hba.conf |         120 | local | {replication} | {all}     |               |                                         | peer          |         | \n           5 | \/var\/lib\/pgsql\/data\/pg_hba.conf |         121 | host  | {replication} | {all}     | 127.0.0.1     | 255.255.255.255                         | scram-sha-256 |         | \n           6 | \/var\/lib\/pgsql\/data\/pg_hba.conf |         122 | host  | {replication} | {all}     | ::1           | ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff | scram-sha-256 |         | \n           7 | \/var\/lib\/pgsql\/data\/pg_hba.conf |         123 | host  | {all}         | {all}     | 192.168.122.0 | 255.255.255.0                           | scram-sha-256 |         | \n<\/pre><\/div>\n\n\n
Finally, we want PostgreSQL to listen for external connections, not only on localhost:<\/p>\n\n\n
\n[root@controller ~]$ su - postgres -c "psql -c '\\dconfig *listen*'"\nList of configuration parameters\n    Parameter     |   Value   \n------------------+-----------\n listen_addresses | localhost\n(1 row)\n[root@controller ~]$ echo "listen_addresses='*'" >> \/var\/lib\/pgsql\/data\/postgresql.auto.conf\n[root@controller ~]$ systemctl restart postgresql\n[root@controller ~]$ su - postgres -c "psql -c '\\dconfig *listen*'"\nList of configuration parameters\n    Parameter     | Value \n------------------+-------\n listen_addresses | *\n(1 row)\n<\/pre><\/div>\n\n\n
That’s it for the preparation of the hosts and leaves us with the following setup:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
In the next post, we’ll start with the deployment and configuration of the first OpenStack service, which is the identity service (Keystone).<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
In the introduction post we’ve briefly looked at some options you have available when you want to build your own private cloud. In this post we’re going to start our journey into OpenStack by preparing the two nodes we’re going to use for this setup: The controller node, and one compute node. Maybe you remember […]<\/p>\n","protected":false},"author":29,"featured_media":0,"comment_status":"open","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[955,1320,83],"tags":[135,73,957,77],"type_dbi":[],"class_list":["post-36601","post","type-post","status-publish","format-standard","hentry","category-cloud","category-devops","category-postgresql","tag-cloud","tag-linux","tag-openstack","tag-postgresql"],"acf":[],"yoast_head":"\nCreating your private cloud using OpenStack \u2013 (2) \u2013 Preparing the nodes - dbi Blog<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.dbi-services.com\/blog\/creating-your-private-cloud-using-openstack-2-preparing-the-nodes\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Creating your private cloud using OpenStack \u2013 (2) \u2013 Preparing the nodes\" \/>\n<meta property=\"og:description\" content=\"In the introduction post we’ve briefly looked at some options you have available when you want to build your own private cloud. In this post we’re going to start our journey into OpenStack by preparing the two nodes we’re going to use for this setup: The controller node, and one compute node. Maybe you remember […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.dbi-services.com\/blog\/creating-your-private-cloud-using-openstack-2-preparing-the-nodes\/\" \/>\n<meta property=\"og:site_name\" content=\"dbi Blog\" \/>\n<meta property=\"article:published_time\" content=\"2025-01-17T06:08:16+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2025-01-20T11:54:33+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2025\/01\/ostack1-1.png\" \/>\n\t<meta property=\"og:image:width\" content=\"1261\" \/>\n\t<meta property=\"og:image:height\" content=\"545\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"Daniel Westermann\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@westermanndanie\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Daniel Westermann\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"13 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/creating-your-private-cloud-using-openstack-2-preparing-the-nodes\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/creating-your-private-cloud-using-openstack-2-preparing-the-nodes\/\"},\"author\":{\"name\":\"Daniel Westermann\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/8d08e9bd996a89bd75c0286cbabf3c66\"},\"headline\":\"Creating your private cloud using OpenStack \u2013 (2) \u2013 Preparing the nodes\",\"datePublished\":\"2025-01-17T06:08:16+00:00\",\"dateModified\":\"2025-01-20T11:54:33+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/creating-your-private-cloud-using-openstack-2-preparing-the-nodes\/\"},\"wordCount\":890,\"commentCount\":0,\"image\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/creating-your-private-cloud-using-openstack-2-preparing-the-nodes\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2025\/01\/ostack1-1-1024x443.png\",\"keywords\":[\"Cloud\",\"Linux\",\"openstack\",\"PostgreSQL\"],\"articleSection\":[\"Cloud\",\"DevOps\",\"PostgreSQL\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/creating-your-private-cloud-using-openstack-2-preparing-the-nodes\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/creating-your-private-cloud-using-openstack-2-preparing-the-nodes\/\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/creating-your-private-cloud-using-openstack-2-preparing-the-nodes\/\",\"name\":\"Creating your private cloud using OpenStack \u2013 (2) \u2013 Preparing the nodes - dbi Blog\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/creating-your-private-cloud-using-openstack-2-preparing-the-nodes\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/creating-your-private-cloud-using-openstack-2-preparing-the-nodes\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2025\/01\/ostack1-1-1024x443.png\",\"datePublished\":\"2025-01-17T06:08:16+00:00\",\"dateModified\":\"2025-01-20T11:54:33+00:00\",\"author\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/8d08e9bd996a89bd75c0286cbabf3c66\"},\"breadcrumb\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/creating-your-private-cloud-using-openstack-2-preparing-the-nodes\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/creating-your-private-cloud-using-openstack-2-preparing-the-nodes\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/creating-your-private-cloud-using-openstack-2-preparing-the-nodes\/#primaryimage\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2025\/01\/ostack1-1.png\",\"contentUrl\":\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2025\/01\/ostack1-1.png\",\"width\":1261,\"height\":545},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/creating-your-private-cloud-using-openstack-2-preparing-the-nodes\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\/\/www.dbi-services.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Creating your private cloud using OpenStack \u2013 (2) \u2013 Preparing the nodes\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#website\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/\",\"name\":\"dbi Blog\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.dbi-services.com\/blog\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/8d08e9bd996a89bd75c0286cbabf3c66\",\"name\":\"Daniel Westermann\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/secure.gravatar.com\/avatar\/31350ceeecb1dd8986339a29bf040d4cd3cd087d410deccd8f55234466d6c317?s=96&d=mm&r=g\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/31350ceeecb1dd8986339a29bf040d4cd3cd087d410deccd8f55234466d6c317?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/31350ceeecb1dd8986339a29bf040d4cd3cd087d410deccd8f55234466d6c317?s=96&d=mm&r=g\",\"caption\":\"Daniel Westermann\"},\"description\":\"Daniel Westermann is Principal Consultant and Technology Leader Open Infrastructure at dbi services. He has more than 15 years of experience in management, engineering and optimization of databases and infrastructures, especially on Oracle and PostgreSQL. Since the beginning of his career, he has specialized in Oracle Technologies and is Oracle Certified Professional 12c and Oracle Certified Expert RAC\/GridInfra. Over time, Daniel has become increasingly interested in open source technologies, becoming \u201cTechnology Leader Open Infrastructure\u201d and PostgreSQL expert. \u00a0Based on community or EnterpriseDB tools, he develops and installs complex high available solutions with PostgreSQL. He is also a certified PostgreSQL Plus 9.0 Professional and a Postgres Advanced Server 9.4 Professional. He is a regular speaker at PostgreSQL conferences in Switzerland and Europe. Today Daniel is also supporting our customers on AWS services such as AWS RDS, database migrations into the cloud, EC2 and automated infrastructure management with AWS SSM (System Manager). He is a certified AWS Solutions Architect Professional. Prior to dbi services, Daniel was Management System Engineer at LC SYSTEMS-Engineering AG in Basel. Before that, he worked as Oracle Developper &\u00a0Project Manager at Delta Energy Solutions AG in Basel (today Powel AG). Daniel holds a diploma in Business Informatics (DHBW, Germany). His branch-related experience mainly covers the pharma industry, the financial sector, energy, lottery and telecommunications.\",\"sameAs\":[\"https:\/\/x.com\/westermanndanie\"],\"url\":\"https:\/\/www.dbi-services.com\/blog\/author\/daniel-westermann\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Creating your private cloud using OpenStack \u2013 (2) \u2013 Preparing the nodes - dbi Blog","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.dbi-services.com\/blog\/creating-your-private-cloud-using-openstack-2-preparing-the-nodes\/","og_locale":"en_US","og_type":"article","og_title":"Creating your private cloud using OpenStack \u2013 (2) \u2013 Preparing the nodes","og_description":"In the introduction post we’ve briefly looked at some options you have available when you want to build your own private cloud. In this post we’re going to start our journey into OpenStack by preparing the two nodes we’re going to use for this setup: The controller node, and one compute node. Maybe you remember […]","og_url":"https:\/\/www.dbi-services.com\/blog\/creating-your-private-cloud-using-openstack-2-preparing-the-nodes\/","og_site_name":"dbi Blog","article_published_time":"2025-01-17T06:08:16+00:00","article_modified_time":"2025-01-20T11:54:33+00:00","og_image":[{"width":1261,"height":545,"url":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2025\/01\/ostack1-1.png","type":"image\/png"}],"author":"Daniel Westermann","twitter_card":"summary_large_image","twitter_creator":"@westermanndanie","twitter_misc":{"Written by":"Daniel Westermann","Est. reading time":"13 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.dbi-services.com\/blog\/creating-your-private-cloud-using-openstack-2-preparing-the-nodes\/#article","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/creating-your-private-cloud-using-openstack-2-preparing-the-nodes\/"},"author":{"name":"Daniel Westermann","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/8d08e9bd996a89bd75c0286cbabf3c66"},"headline":"Creating your private cloud using OpenStack \u2013 (2) \u2013 Preparing the nodes","datePublished":"2025-01-17T06:08:16+00:00","dateModified":"2025-01-20T11:54:33+00:00","mainEntityOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/creating-your-private-cloud-using-openstack-2-preparing-the-nodes\/"},"wordCount":890,"commentCount":0,"image":{"@id":"https:\/\/www.dbi-services.com\/blog\/creating-your-private-cloud-using-openstack-2-preparing-the-nodes\/#primaryimage"},"thumbnailUrl":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2025\/01\/ostack1-1-1024x443.png","keywords":["Cloud","Linux","openstack","PostgreSQL"],"articleSection":["Cloud","DevOps","PostgreSQL"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.dbi-services.com\/blog\/creating-your-private-cloud-using-openstack-2-preparing-the-nodes\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.dbi-services.com\/blog\/creating-your-private-cloud-using-openstack-2-preparing-the-nodes\/","url":"https:\/\/www.dbi-services.com\/blog\/creating-your-private-cloud-using-openstack-2-preparing-the-nodes\/","name":"Creating your private cloud using OpenStack \u2013 (2) \u2013 Preparing the nodes - dbi Blog","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/creating-your-private-cloud-using-openstack-2-preparing-the-nodes\/#primaryimage"},"image":{"@id":"https:\/\/www.dbi-services.com\/blog\/creating-your-private-cloud-using-openstack-2-preparing-the-nodes\/#primaryimage"},"thumbnailUrl":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2025\/01\/ostack1-1-1024x443.png","datePublished":"2025-01-17T06:08:16+00:00","dateModified":"2025-01-20T11:54:33+00:00","author":{"@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/8d08e9bd996a89bd75c0286cbabf3c66"},"breadcrumb":{"@id":"https:\/\/www.dbi-services.com\/blog\/creating-your-private-cloud-using-openstack-2-preparing-the-nodes\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.dbi-services.com\/blog\/creating-your-private-cloud-using-openstack-2-preparing-the-nodes\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.dbi-services.com\/blog\/creating-your-private-cloud-using-openstack-2-preparing-the-nodes\/#primaryimage","url":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2025\/01\/ostack1-1.png","contentUrl":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2025\/01\/ostack1-1.png","width":1261,"height":545},{"@type":"BreadcrumbList","@id":"https:\/\/www.dbi-services.com\/blog\/creating-your-private-cloud-using-openstack-2-preparing-the-nodes\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/www.dbi-services.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Creating your private cloud using OpenStack \u2013 (2) \u2013 Preparing the nodes"}]},{"@type":"WebSite","@id":"https:\/\/www.dbi-services.com\/blog\/#website","url":"https:\/\/www.dbi-services.com\/blog\/","name":"dbi Blog","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.dbi-services.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/8d08e9bd996a89bd75c0286cbabf3c66","name":"Daniel Westermann","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/31350ceeecb1dd8986339a29bf040d4cd3cd087d410deccd8f55234466d6c317?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/31350ceeecb1dd8986339a29bf040d4cd3cd087d410deccd8f55234466d6c317?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/31350ceeecb1dd8986339a29bf040d4cd3cd087d410deccd8f55234466d6c317?s=96&d=mm&r=g","caption":"Daniel Westermann"},"description":"Daniel Westermann is Principal Consultant and Technology Leader Open Infrastructure at dbi services. He has more than 15 years of experience in management, engineering and optimization of databases and infrastructures, especially on Oracle and PostgreSQL. Since the beginning of his career, he has specialized in Oracle Technologies and is Oracle Certified Professional 12c and Oracle Certified Expert RAC\/GridInfra. Over time, Daniel has become increasingly interested in open source technologies, becoming \u201cTechnology Leader Open Infrastructure\u201d and PostgreSQL expert. \u00a0Based on community or EnterpriseDB tools, he develops and installs complex high available solutions with PostgreSQL. He is also a certified PostgreSQL Plus 9.0 Professional and a Postgres Advanced Server 9.4 Professional. He is a regular speaker at PostgreSQL conferences in Switzerland and Europe. Today Daniel is also supporting our customers on AWS services such as AWS RDS, database migrations into the cloud, EC2 and automated infrastructure management with AWS SSM (System Manager). He is a certified AWS Solutions Architect Professional. Prior to dbi services, Daniel was Management System Engineer at LC SYSTEMS-Engineering AG in Basel. Before that, he worked as Oracle Developper &\u00a0Project Manager at Delta Energy Solutions AG in Basel (today Powel AG). Daniel holds a diploma in Business Informatics (DHBW, Germany). His branch-related experience mainly covers the pharma industry, the financial sector, energy, lottery and telecommunications.","sameAs":["https:\/\/x.com\/westermanndanie"],"url":"https:\/\/www.dbi-services.com\/blog\/author\/daniel-westermann\/"}]}},"_links":{"self":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/36601","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/users\/29"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/comments?post=36601"}],"version-history":[{"count":26,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/36601\/revisions"}],"predecessor-version":[{"id":36756,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/36601\/revisions\/36756"}],"wp:attachment":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media?parent=36601"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/categories?post=36601"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/tags?post=36601"},{"taxonomy":"type","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/type_dbi?post=36601"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}