• Recent
  • Unsolved
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Register
  • Login
  • Recent
  • Unsolved
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Register
  • Login

Rolling FOG out to US Site

Scheduled Pinned Locked Moved Solved
General
5
97
46.4k
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • G
    george1421 Moderator @RobTitian16
    last edited by Oct 11, 2016, 2:21 PM

    @RobTitian16 I only mentioned the script and its intended function because it would do what you needed to re-ip a host. But I agree with Wayne maybe a simpler one time run script would be in order, because sometimes you DO have to renumber a FOG server after its been setup.

    Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

    1 Reply Last reply Reply Quote 0
    • R
      RobTitian16 @Wayne Workman
      last edited by Oct 11, 2016, 4:05 PM

      @Wayne-Workman Many thanks, gents. It all seems to be working here in the UK so I’ll ship it out tomorrow and hopefully set up the new VM later on this week/next week.
      If I run into any issues I’ll post back 🙂

      1 Reply Last reply Reply Quote 1
      • R
        RobTitian16 @Tom Elliott
        last edited by Oct 27, 2016, 11:50 AM

        This post is deleted!
        1 Reply Last reply Reply Quote 0
        • R
          RobTitian16 @Wayne Workman
          last edited by Nov 1, 2016, 9:25 AM

          @Wayne-Workman Thanks for this, Wayne. Is it normal to see:

          [11-01-16 9:14:18 am] | Image name: Win7Clientx86
          [11-01-16 9:14:18 am] * Found Image to transfer to 1 node(s)

          On both the master node in the UK and the US storage node? I can’t see any received data on the US FOG server, so I’m concerned that the replication is not working correctly.

          G 1 Reply Last reply Nov 1, 2016, 9:41 AM Reply Quote 0
          • G
            george1421 Moderator @RobTitian16
            last edited by Nov 1, 2016, 9:41 AM

            @RobTitian16 Is the US server a full FOG server or a storage node?

            If both are full fog servers then you only configure the master server for the UK, the US fog server shall think its standalone. So you don’t setup any storage groups or anything. That is all done on the UK server.

            Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

            R 1 Reply Last reply Nov 1, 2016, 10:28 AM Reply Quote 0
            • R
              RobTitian16 @george1421
              last edited by Nov 1, 2016, 10:28 AM

              @george1421 The US server is a full FOG server, but it’s listed as a storage node on the UK server. The only storage nodes on the US server are its own.

              T 1 Reply Last reply Nov 1, 2016, 10:29 AM Reply Quote 0
              • T
                Tom Elliott @RobTitian16
                last edited by Nov 1, 2016, 10:29 AM

                @RobTitian16 Are they associated to groups? If they are, is there another group they can belong to?

                Replication only happens on nodes from a master->subordinate system. This is only with per group.

                If an image belongs to multiple groups, though, the “primary” group will be the master and it will only distribute to other master nodes (as the master nodes will distribute to their group’s subordinates).

                Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG! Get in contact with me (chat bubble in the top right corner) if you want to join in.

                Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)

                Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG

                R 1 Reply Last reply Nov 1, 2016, 10:46 AM Reply Quote 0
                • R
                  RobTitian16 @Tom Elliott
                  last edited by Nov 1, 2016, 10:46 AM

                  @Tom-Elliott Yes, on the UK server the images I want to replicate belong to the primary storage group called UK, and a secondary storage group called US.
                  The US server is listed as a storage node on the UK server, although I’ve just noticed it isn’t listed as a master node. The UK server is in its own storage group, as is the US server, so I assume all I need to do is enable the US server as a master node and it should then work?
                  P.S. sorry if it seems like a dumb question… I just don’t want replication to occur the wrong way/have the images wiped.

                  T 1 Reply Last reply Nov 1, 2016, 10:49 AM Reply Quote 0
                  • T
                    Tom Elliott @RobTitian16
                    last edited by Nov 1, 2016, 10:49 AM

                    @RobTitian16 Replication will only go Primary Master->Master between groups.

                    Replication will only go Master -> Subordinate within their respective groups.

                    I don’t know how else to make it clear.

                    Every group MUST have at least one “master” node. If one is not defined but there’s only one node in the group that node will “be” the master for that group (as it’s the only one available anyway).
                    If one is not defined and there’s multiple nodes in the group, the “Oldest” created node of that group will be assumed as the master until otherwise stated.

                    Replication doesn’t work “up the tree” if you will.

                    Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG! Get in contact with me (chat bubble in the top right corner) if you want to join in.

                    Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)

                    Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG

                    R 1 Reply Last reply Nov 1, 2016, 11:06 AM Reply Quote 0
                    • R
                      RobTitian16 @Tom Elliott
                      last edited by Nov 1, 2016, 11:06 AM

                      @Tom-Elliott Ahh okay, thanks. I’ve changed it to the master node now for that group, so I shall wait and see what happens in that case.

                      T 1 Reply Last reply Nov 1, 2016, 11:13 AM Reply Quote 0
                      • T
                        Tom Elliott @RobTitian16
                        last edited by Tom Elliott Nov 1, 2016, 5:15 AM Nov 1, 2016, 11:13 AM

                        @RobTitian16 I feel I should add some caveats to this.

                        The replication process is self monitored. If a replication task was started, but has not completed, the next cycle will be aware of this and will not try to replicate the file over. If replication has completed between two points and both sides have the same files the images will not be touched.

                        Only items (Snapins and Images) that are defined as “to Replicate” will be replicated.

                        Any extra data within a storage location (snapins or images) will not be removed unless that data is defined within the main system and told to do so.

                        For example, let’s say you decided to create a backup of image1 and you locally backed it up on a node that is not a “master”. You locally backup image1 with the name of image1_backUp within the Images storage location. image1_backUp will be untouched.

                        If you made a backup in the same fashion, but on a master node, that data will not be replicated to other nodes.

                        Only defined items will be replicated. Data loss is limited due to this implementation. At one point, FOG did used to replicate it’s images folder implicitly. This meant anything that was not a part of the “master’s” data record on another node would be removed and only the data within the master would be available on any node. This, essentially, meant that you could not maintain backup’s of things from other nodes without having to have another location available on that system. This also meant you had no granular control over what can/cannot be replicated. This is where the “Master Node” warning came from. I have not updated it because I think it’s better to be “cautious” in the case something weird does happen.

                        Essentially, the methods to replicate images and snapins are now much better controlled (I think) with less potential of data loss.

                        Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG! Get in contact with me (chat bubble in the top right corner) if you want to join in.

                        Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)

                        Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG

                        R 1 Reply Last reply Nov 1, 2016, 12:01 PM Reply Quote 0
                        • G
                          george1421 Moderator
                          last edited by Nov 1, 2016, 11:28 AM

                          While its probably not necessairy to post this image, this is from my initial request for a multi master storage node setup. The intent was to show the relationship between the master node and the remote fog servers.

                          0_1477999589815_1446141198641-storage_network.jpg

                          ref: https://forums.fogproject.org/topic/6014/create-the-concept-of-a-foreignmasterstorage-deployment-node

                          Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

                          R 1 Reply Last reply Nov 1, 2016, 2:23 PM Reply Quote 2
                          • R
                            RobTitian16 @Tom Elliott
                            last edited by Nov 1, 2016, 12:01 PM

                            @Tom-Elliott Indeed, that all does make sense. Many thanks for your help! I can see the replication is going across perfectly fine.
                            One thing to note: I had to use the local account and the password for the ftp access, instead of the username and password listed in /opt/fog/.fogsettings (which is what it says in step 12 of https://wiki.fogproject.org/wiki/index.php?title=Managing_FOG#Storage_Management).

                            T 1 Reply Last reply Nov 1, 2016, 12:50 PM Reply Quote 0
                            • T
                              Tom Elliott @RobTitian16
                              last edited by Nov 1, 2016, 12:50 PM

                              @RobTitian16 The management user and password are the local linux account on the Storage nodes. If those aren’t matching something else is wrong.

                              The user is typically “fog” and the password is a randomly generated one during the installation which is stored in the “password” item of the .fogsettings file.

                              Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG! Get in contact with me (chat bubble in the top right corner) if you want to join in.

                              Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)

                              Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG

                              1 Reply Last reply Reply Quote 0
                              • Wayne WorkmanW
                                Wayne Workman
                                last edited by Wayne Workman Nov 1, 2016, 6:59 AM Nov 1, 2016, 12:57 PM

                                Given that @RobTitian16 is new to this, I’m going to say the issue is something simple.

                                Rob, if you aren’t using the exact password that is inside of /opt/fog/.fogsettings for all the “storage nodes” you have listed in the “real” main server, the very next time you update fog, replication will break. Why? Because the FOG installer manages the local fog account, meaning the FOG installer will make sure the password for the local fog account is exactly as written in the .fogsettings file. And because you’re using a multi-master setup, you don’t have available the built-in safe-guards that the Storage Node portion of the FOG installer has in it, which already have measures to prevent this type of breakage.

                                You should not be using the local fog account for anything, it’s very bad practice to do so. It should be reserved exclusively and only for FOG’s use. Create some other account for yourself to use.

                                Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!
                                Daily Clean Installation Results:
                                https://fogtesting.fogproject.us/
                                FOG Reporting:
                                https://fog-external-reporting-results.fogproject.us/

                                R 2 Replies Last reply Nov 1, 2016, 2:22 PM Reply Quote 0
                                • R
                                  RobTitian16 @Wayne Workman
                                  last edited by Nov 1, 2016, 2:22 PM

                                  @Wayne-Workman Thanks for explaining 🙂
                                  Everything seems to be working as expected now so hopefully I’ll be seeing the new image on the US server shortly 🙂

                                  1 Reply Last reply Reply Quote 0
                                  • R
                                    RobTitian16 @george1421
                                    last edited by Nov 1, 2016, 2:23 PM

                                    @george1421 Very interesting - thanks for posting! It definitely helps to see it like that.

                                    1 Reply Last reply Reply Quote 0
                                    • R
                                      RobTitian16 @Wayne Workman
                                      last edited by Nov 2, 2016, 10:37 AM

                                      @Wayne-Workman Just one final thing on this: would the replicated images on the US server show that they’ve been updated at all?
                                      For example, if I’ve updated an image here in the UK, then see the replication has finished comparing and matching the files, should it say anything when looking at the image in the web gui (i.e. last updated) on the US server? Or do you just purely go by the replication log?

                                      Wayne WorkmanW 1 Reply Last reply Nov 2, 2016, 11:59 AM Reply Quote 0
                                      • Wayne WorkmanW
                                        Wayne Workman @RobTitian16
                                        last edited by Nov 2, 2016, 11:59 AM

                                        @RobTitian16 Because the two servers each have their own DB, one DB knows about the new upload, the other doesn’t.

                                        Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!
                                        Daily Clean Installation Results:
                                        https://fogtesting.fogproject.us/
                                        FOG Reporting:
                                        https://fog-external-reporting-results.fogproject.us/

                                        1 Reply Last reply Reply Quote 1
                                        • R
                                          RobTitian16
                                          last edited by Nov 10, 2016, 2:19 PM

                                          I wonder if anyone can help me with a further question I have about the US FOG server and the FOG client.

                                          As it stands, I need the US images to have the FOG client installed which then connect to the US FOG server. However, because replication is occurring between the UK (which is the main server) and the US, it’s replicating the images with the FOG client which are configured to connect to the UK server.
                                          I don’t want to turn replication off, but I need the FOG client on the US images to connect to the US FOG client. Is this possible at all? i.e. perhaps through a script or is there a way that FOG can install the client on a newly imaged system that’s configured for the server it pulled the image from? How do others work around this issue?

                                          T 1 Reply Last reply Nov 10, 2016, 2:24 PM Reply Quote 0
                                          • 1
                                          • 2
                                          • 3
                                          • 4
                                          • 5
                                          • 2 / 5
                                          • First post
                                            Last post

                                          177

                                          Online

                                          12.1k

                                          Users

                                          17.3k

                                          Topics

                                          155.3k

                                          Posts
                                          Copyright © 2012-2024 FOG Project