New install failing

[xburnerx00]

I am trying to install 1.5.9 onto Cent OS 7. Using the instruction found on the wiki, I eventually get an error.

OK
 * Backing up user reports.....................................Done
 * Stopping web service........................................OK
 * Setting up Apache and PHP files.............................OK
 * Testing and removing symbolic links if found................OK
 * Backing up old data.........................................OK
 * Copying new files to web folder.............................OK
 * Creating config file........................................OK
 * Creating redirection index file.............................Skipped
 * Downloading kernel, init and fog-client binaries............Done
 * Copying binaries to destination paths.......................OK
 * Enabling apache and fpm services on boot....................OK
 * Creating SSL CA.............................................OK
 * Creating SSL Private Key....................................Failed!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!! The installer was not able to run all the way to the end as   !!
!! something has caused it to fail. The following few lines are  !!
!! from the error log file which might help us figure out what's !!
!! wrong. Please add this information when reporting an error.   !!
!! As well you might want to take a look at the full error log   !!
!! in /root/git/fogproject/bin/error_logs/fog_error_1.5.9.log !!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

........++
.........................................................++
e is 65537 (0x10001)
error on line 7 of /opt/fog/snapins/ssl//req.cnf
140189682390928:error:0E079065:configuration file routines:DEF_LOAD_BIO:missing equal sign:conf_def.c:345:line 7

I check the file that the file log is referencing.
/opt/fog/snapins/ssl//req.cnf

[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = yes
[req_distinguished_name]
CN = 10.4.6.44
10.4.1.101
[v3_req]
subjectAltName = @alt_names
[alt_names]
IP.1 = 10.4.6.44
10.4.1.101
DNS.1 = FOG2

Not sure what’s going.

Thank you.

[Sebastian Roth]

@xburnerx00 said in New install failing:

CN = 10.4.6.44
10.4.1.101

Looks like you have two IP addresses configured (just guessing) and that is causing an issue. Please run ip a s and post the full output here.

[xburnerx00]

@sebastian-roth
Thank you for the reply.
Output of ip a s

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether ec:b1:d7:39:d3:43 brd ff:ff:ff:ff:ff:ff
    inet 10.4.6.44/21 brd 10.4.7.255 scope global noprefixroute dynamic eno1
       valid_lft 608102sec preferred_lft 608102sec
    inet 10.4.1.101/21 brd 10.4.7.255 scope global secondary noprefixroute eno1
       valid_lft forever preferred_lft forever
    inet6 fe80::e4a8:f3be:9a11:7d2b/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 52:54:00:cc:59:bc brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
       valid_lft forever preferred_lft forever
4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN group default qlen 1000
    link/ether 52:54:00:cc:59:bc brd ff:ff:ff:ff:ff:ff

[Sebastian Roth]

@xburnerx00 Are you aware of the two IPs being bound to interface eno1? The FOG installer does not seem to handle this well and I can imagine multicasting and other things might cause trouble as well.

[xburnerx00]

@sebastian-roth

Thank you for pointing that out. I changed the settings to manual, as it was already set to DHCP. After that, I reran the install and it completed. I do not know why there was two addresses. When I installed Cent OS, I input an ip address. I guess when it finished the install it was set for dynamic and picked up an IP but still had the manual one set.

[Wayne Workman]

@xburnerx00 said in New install failing:

I changed the settings to manual, as it was already set to DHCP.

I’ve seen this behavior lots of times with Linux. If you do a DHCP release / renew with these commands:

dhclient -r && dhclient

it produces the same behavior. the old address is held on the interface along with the new one. I’ve found that rebooting clears it. I’ve not tried other things.

Reference: https://linux.die.net/man/8/dhclient

I’ll work on a check for detecting two IPs on the chosen interface. If there are two, the installer should note this and exit rather than falling on it’s face and people not knowing what’s going on. It can also offer advice on how to fix (like rebooting)

[Tom Elliott]

@wayne-workman @Sebastian-Roth what if we allowed the virtual IP but as subject alternate names? Like a bash array that we take the first in the list and make it the CN, and anything additional as the SANs of the certificate chain?

[Sebastian Roth]

@xburnerx00 said in New install failing:

I changed the settings to manual, as it was already set to DHCP.

Definitely set manual IP on a FOG server. If the IP changes you’d have a problem.

[Wayne Workman]

@tom-elliott if that were implemented, then in @xburnerx00’s case his certificate would have an IP that the FOG server isn’t using after one reboot.

In what legitimate case does a single Linux interface have two IPs?

[Tom Elliott]

@wayne-workman the problem is we can’t and shouldn’t know or assume for all cases. I have worked for an organization who had not 1, not 2, but 5 IPs on a single interface. Routing was not fun on that machine. The point here, is it can happen and for that reason we should adapt. I cannot delve into why the machine needed 5 IPs on the interface, just know that it happens.

[Wayne Workman]

@tom-elliott in that case, I would agree that putting the extras into the SANs is appropriate. I’ll see if I can figure this out.

[Sebastian Roth]

@Tom-Elliott @Wayne-Workman In this case here the installer error was actually helpful to prevent from later issues with two IPs on an interface that were not intentionally configured.

I don’t think it’s worth the effort changing the scripts but feel free to go ahead.