As I mentioned in the original post, I already fixed my issues.
My original question still remains, does something need to be mentioned on the migration wiki page about this or was it just a one off issue. If it is not an isolated issue, I think it is appropriate to let people know that they will need to setup their groups again as well as the host service settings.
@george1421 About 500 hosts. I am not sure what you are suggesting here is on topic since the post is about the Host Service Settings and Group Membership and not the images.
Sweet. Ran the delete statement and it fixed the issue. I will pull the latest version down in the morning and rerun the installer.
Thanks for the quick response everyone!
Here is what I found from the database tables. Here is the list of members from a group that I create with just two hosts.
mysql> select * from groupMembers where gmGroupID=68;
+------+----------+-----------+
| gmID | gmHostID | gmGroupID |
+------+----------+-----------+
| 1911 | 880 | 68 |
| 1910 | 0 | 68 |
| 1912 | 879 | 68 |
+------+----------+-----------+
3 rows in set (0.00 sec)
HostIDs 880 and 879 real host. It is the second entry (HostID 0) that is for a fake host.
mysql> select * from hosts where hostID = 0;
Empty set (0.00 sec)
Might be a loop iteration issue.
I do have the sql backup from the old server. Whom should I email it to?
FOG:
Running Version 8355
SVN Revision: 5805
Creating groups from the Host Management page adds a phantom Group Member.
Steps to reproduce:
This only occurs if you create the group from the Host Management page. If you create the group from the Group Management page and then add hosts from either the Group page or the Host Management page, the member number is correct.
Server Information:
OS: Ubunu 16.04
Apache2 - PHP 7.0
Fog:
Running Version 8355
SVN Revision: 5805
I followed the instructions for migration from 0.32 to 1.x.x from the wiki (https://wiki.fogproject.org/wiki/index.php?title=Upgrade_to_1.x.x#Migration_Upgrade) and for the most part it was successful. I did run into the following issues though.
The first two items, were not really a big deal for me. Inconvenient, but not too bad to recreate. Plus, it was a major upgrade so one should expect to have to recreate some settings. For me I just re-added the hosts to the appropriate groups and then used the group to set the service settings.
Has any one else experienced these issues? Is it something that should be added to the wiki page on migration?
I am currently working on converting my FOG server from OpenVZ to LXC. I am no expert, but here is what I did to get the NFS Server running inside the container.
I run Proxmox 4.x but this should work for LXC in general. These instructions are from a post on the Proxmox Forum (https://forum.proxmox.com/threads/advice-for-file-sharing-between-containers.25704/#post-129006) and tweaked just a little.
LXC OS: Ubuntu 16.04
FOG Version: 1.3.0 (pulled from git)
By default LXC has Apparmor enabled. There are two choices here, disable Apparmor or create a profile to allow NFS. I do not recommend disabling Apparmor, but it can be helpful for testing purposes.
Option 1 - Disable Apparmor:
lxc.aa_profile: unconfined./etc/pve/lxc/CTID.conf, where CTID is the ID number of the container.Option 2 - Create an Apparmor profile that allows NFS:
/etc/apparmor.d/lxc/lxc-default-with-nfs with the following content.# Do not load this file. Rather, load /etc/apparmor.d/lxc-containers, which
# will source all profiles under /etc/apparmor.d/lxc
profile lxc-container-default-with-nfs flags=(attach_disconnected,mediate_deleted) { #include <abstractions/lxc/container-base>
# allow NFS (nfs/nfs4) mounts.
mount fstype=nfs*,
mount fstype=rpc_pipefs,
}
apparmor_parser -r /etc/apparmor.d/lxc-containerslxc.aa_profile: lxc-container-default-with-nfs./etc/pve/lxc/CTID.conf, where CTID is the ID number of the container.Make sure to restart your container after you make any changes to the configuration file.
Hope this helps!