@Sebastian-Roth, @TBuzaTechnician
If you run mysqladm --user root password "newpassword", you should not do it as a part of the installation script (eventually yes, but as of right now no.)
After you set the password, then you can run it with snmysqlpass='newpassword' ./installfog.sh -y
Eventually, I know we want to create a separate user and password pair for mysql for security reasons, but in the mean time, the above should work.
Another option that doesn’t seem to loop forever:
head /dev/urandom | tr -dc '0-9a-zA-Z!#$%&()*+,-./:;<=>?@[]^_{|}~' | fold -w12 | shuf -n1
What this one does, it breaks at the first new line urandom gives (so much faster return and not infinite loop), pipes that output to tr, folds it to a width of 12 characters, and shuffles the data returned from the fold.
Hopefully this may help?
The other method is to use most of the stuff but for removing packages, source in the .fogsettings file before you remove the /opt/fog/ folder. Then you can use packagemanager-uninstallcmd $packages
Note this will simply remove the packages fog installs. All the other bits of service removal and what not should work as indicated.
I kind of side with @Sebastian-Roth however because removing all the installed packages can sometimes uninstall elements unexpectedly and out of “fogs” control. I’ve seen occasionally some like like installing python then uninstalling it breaking package manager tools like yum or apt
@george1421 That is because the separate storage group has a master. It’s a “work around” to the “Images are always captured to the master node” because you, quite literally, are making the storage node, now, a master node. It works of course for this reason.
@Sebastian-Roth I think we just need to refine the code a bit more. I don’t know why it’s getting the error, I just know what we did int he past for the passwords. I’m sure we can make a more proper fix without limiting what passwords an admin can use.
@Sebastian-Roth Thank you for finding and fixing the issue.
@Greg-Plamondon Thanks for reporting. This fix is also set for 1.6 now too.
Awesome job everybody!
Thank you,
I found and believe I may have fixed the issue. It was actually pretty simple. The error was coming from the unpacking of information.
Hopefully it helps. Just repull the dev-branch and install and all should be back to normal.
I’m really confused by all of this.
Your Image definition displays as /images/05_09_2019_si_essa, but the warning message from the machine you’re having issues with is displaying /images/28_10_2019_si/ as the image location.
Too me, this seems like the host you’re imaging has a different image assigned to it.
So the setup per redhat documentation:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/installation_guide/chap-anaconda-boot-options
In particular, remove the // as the installer documentation shows it’s not to be set with nfs://
inst.repo=nfs:${fog-ip}:/images/os/centos7-dvd
@rockinhc At one time, maybe the nfs:// worked fine, but it’s since been deprecated and as a part of that, i imagine when @george1421 created that article, the OS version wasn’t at the version it is now. Even though it’s still CentOS 7, its incremental upgrades may have removed the deprecated options as well.
On Ubuntu 18.04 it’s mariadb-server I think
@dsoden @Sebastian-Roth @george1421
Please provide the error log from : /var/log/php-fpm/www-error.log
This will provide the error causing your White Screen.
The issue with CentOS 8 is being addressed, but we need information.
You’re right that opensource works when it works, and believe me, we want to help and get this fixed.
Changing the hostname, for fog, does not change the hostname for the machine. This is more related to updating the SSL certificates based on the DNS Server.
The installer tries to do everything it can for you, but there are areas we try not to change, such as the physical machine hostname as there could be any number of reasons this is setup as such.
Can you explain how it’s things are worse?
I want to help, and I’m 100% sure we can get this fixed and running for you. I just need information to be able to do that. I actually have a CentOS 8 server running for testing at work.
No amount of bickering, backtalk, or anything (from anyone) is going to help that.
@Keating178 The Invalid Storage Group error you were seeing should be fixed if you can upgrade to the latest within the dev-branch from GIT.
Hopefully this will fix the issue you were seeing too.
I have identified a few more issues and been able to correct them.
Clicking on pages within the menu as opposed to full refresh on the same page, some elements such as list -> select items to delete, click delete, the modal not appearing requesting password to ensure you want to do this. On full refresh to link it worked. On clicking from the menu it didn’t. Fixed by causing reinitialization.
Import elements didn’t return proper notification items. Similarly warnings and info notifications always assumed error. This has been fixed
Added rudimentary file upload progress system. Will be working to implement a progress indicator.
Creating images when entering the name, the path didn’t auto populate. This has been re-implemented.
Snapin file uploads were already set to be operational, but did not work due to typo on the POST field to send up the files. Renamed and introduced.
Host export didn’t properly indicate the primac field. It didn’t even pull in the Mac at all and the values were improper. The host name appeared in description, and name field was the spot Mac was trying to populate. Added the primac field and properly pulling the data now.
Along with the reinitialization for the modal requesting passwords, this same reinitialization was causing table populating to be reinitialization and throw an error as it already existed. Set to retrieve so not to throw the error.
@Sebastian-Roth the Macs are being captured as raw, which captures the entire disk, not the partitions.
Would you mind trying on working-1.6? (Preferabbly the same database but on a test instance?) to see if performance is improved at all?
@maverick2041 I found the issue and was able to add a fix for it.
Please run a git pull and reinstall.
Of the fix also 2 little features come in:
A refresh button for the Data tables, so you can force a refresh of the data within the table being seen.
Added whoami route to the API. This returns a json formatted string with the following information:
{"ipaddress": "275.275.275.275", "hostname": "fogserver", "osid": "1", "osname": "Redhat", "installtype": "N"}
The 275 is meant to ensure nobody guesses a proper IP.
Hopefully this will allow snapins to work properly in 1.6
@jeremyvdv Spanning tree enables the ports to wait for a period of time between link up/link down before the switch will pass the information to the machine in case there’s a link connected back to itself on the switch.
This up/down time can be around 27 seconds in normal Spanning tree mode. This would explain why during the automated portion the device cannot get a link or IP, but once at the terminal and restarting the networking it will pick it up.
If your network is using spanning tree, if you can do so, disable it, or if not it’s best to use one of the Fast/Rapid stp methodologies as their up/down time is much more significantly reduced.
@ty900000 I just pushed another update, though it may be a little while before the artifacts are ready for testing.
I’m fairly sure the issue here has to be the FIFO. I’ve also gotten rid of the “Maybe check the fog server to ensure disk space is good to go” by providing the available disk space. It also adds the exact command that partclone is trying to use so we can see what’s going on.
2060 is just the case statement, so I don’t think it’s failing because of the case. I think it’s failing because the FIFO was still open. To combat this, I’ve added a 5 second wait to let the disk settle and release the information for the FIFO so we can remove it to recreate it later on.
@TOXYKILLER Here’s what I find for one of your IP’s (if this is you then cool, but still a bit on the “whoa wait a minute” side)
Source: whois.arin.net
IP Address: 11.101.149.115
Name: DODIIS
Handle: NET-11-0-0-0-1
Registration Date: 1/19/84
Range: 11.0.0.0-11.255.255.255
Org: DoD Network Information Center
Org Handle: DNIC
Address: 3990 E. Broad Street
City: Columbus
State/Province: OH
Postal Code: 43218
Country: United States
What does this mean?
Well DoD own’s the IP Space in its entirety of 11.X.X.X (Including 11.101.X.X).