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

Need ability to unpublish captured image

Scheduled Pinned Locked Moved Solved
Feature Request
3
20
4.3k
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.
  • W
    Wayne Workman @george1421
    last edited by Wayne Workman Dec 1, 2015, 11:02 AM Dec 1, 2015, 5:01 PM

    @george1421 You missed what I was saying.

    The replicator doesn’t care what is in the /images directory. It checks with the DB and finds out from the DB what to copy. If the DB says “These images are in this storage group, these are the nodes in this group” then the replicator will copy those images across those nodes.

    If you create a 2nd storage group and 2nd storage node in that group (on the same master server), then those images will not replicate - because the DB says so.

    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/

    G 1 Reply Last reply Dec 1, 2015, 5:05 PM Reply Quote 0
    • W
      Wayne Workman
      last edited by Dec 1, 2015, 5:05 PM

      You can have more than one storage node configured on a machine. And as long as image names do not conflict - the storage nodes can even use the same directory.

      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 0
      • G
        george1421 Moderator @Wayne Workman
        last edited by george1421 Dec 1, 2015, 11:07 AM Dec 1, 2015, 5:05 PM

        @Wayne-Workman I’ll have to confirm that. The last time I checked all files in the /images folder was replicated to the storage nodes even if they were not specifically called out in an image or the database. The only exception was if the images were in */dev and */ca.

        I can test this today since I just rebuilt the POC system this AM with the latest build. But again, I want to avoid having to dive into the OS to move things around. While I have the necessary skills to do this, not everyone will or should have the access to do this.

        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!

        W 1 Reply Last reply Dec 1, 2015, 8:40 PM Reply Quote 0
        • W
          Wayne Workman @george1421
          last edited by Dec 1, 2015, 8:40 PM

          @george1421 said:

          But again, I want to avoid having to dive into the OS to move things around.

          I don’t think you have to if you use the same images directory that already exists on your master 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!
          Daily Clean Installation Results:
          https://fogtesting.fogproject.us/
          FOG Reporting:
          https://fog-external-reporting-results.fogproject.us/

          1 Reply Last reply Reply Quote 0
          • T
            Tom Elliott
            last edited by Dec 2, 2015, 12:20 AM

            The current replicators in svn check the individual files/folders, not just simply replicate the folder as is.

            That said, I totally can see the need for enabling/disabling items. We already use a method for it in handling storage nodes, why can’t we use that same ideology for images and/or snapins? I suppose we could use it in other areas too, but still.

            So without any further ado, I am pleased to state that this is now added. I even made the selectors know about this. Meaning that the drop down lists will display only enabled items if the isEnabled flag is within the class. That also means it could be relatively easy to port to other classes/plugins too.

            In either case here you go and I hope it does what you want/need.

            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

            W G 3 Replies Last reply Dec 2, 2015, 12:35 AM Reply Quote 1
            • W
              Wayne Workman @Tom Elliott
              last edited by Dec 2, 2015, 12:35 AM

              @Tom-Elliott Awesome.

              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
              • T
                Tom Elliott
                last edited by Dec 2, 2015, 12:56 AM

                Replicator flag has now been added as well. This will keep the image or snapin (or whatever) from replicating to other nodes/groups. Paired with the “enabled” element, it means the image can be fully unpublished, in theory. Not meaning you can’t add/edit the items but rather it will do, I hope, what was requested.

                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

                G 1 Reply Last reply Dec 2, 2015, 1:22 AM Reply Quote 0
                • G
                  george1421 Moderator @Tom Elliott
                  last edited by Dec 2, 2015, 1:20 AM

                  @Tom-Elliott said:

                  So without any further ado, I am pleased to state that this is now added. I even made the selectors know about this. Meaning that the drop down lists will display only enabled items if the isEnabled flag is within the class. That also means it could be relatively easy to port to other classes/plugins too.

                  In either case here you go and I hope it does what you want/need.

                  ^^ I wish I could up vote this 100 times. Well done!! I’ll check this out to see how it works a bit later. But this will help us by allowing us to keep our FOG environment simple (i.e. without isolated dev FOG server, complex scripts to hide or move images around).

                  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
                  • G
                    george1421 Moderator @Tom Elliott
                    last edited by Dec 2, 2015, 1:22 AM

                    @Tom-Elliott said:

                    Replicator flag has now been added as well. This will keep the image or snapin (or whatever) from replicating to other nodes/groups. Paired with the “enabled” element, it means the image can be fully unpublished, in theory. Not meaning you can’t add/edit the items but rather it will do, I hope, what was requested.

                    As long as the replicators honor the unpublished flag then we should be good. This should keep the image on the master FOG server until we have it approved for deployment.

                    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!

                    W 1 Reply Last reply Dec 2, 2015, 2:11 AM Reply Quote 0
                    • W
                      Wayne Workman @george1421
                      last edited by Wayne Workman Dec 1, 2015, 8:15 PM Dec 2, 2015, 2:11 AM

                      @george1421 I think the replicator will act as usual - but will check if the replicator flag is set. If it’s not set, no replication.

                      If the Enabled flag is set determines if the image is selectable (and therefore assignable) to a host.

                      That’s how I interpreted it anyways.

                      So for a image dev in your company, I suppose they would initially just disable the replicator flag. Once the image is assigned to their one/two test machines, they would then clear the enable flag also so that nobody else can select the image.

                      @Tom-Elliott Does the above sound accurate?

                      I think it wouldn’t be good if the Enable flag prevented image capture/deployment (if the image was previously assigned to a host).

                      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/

                      G 1 Reply Last reply Dec 2, 2015, 3:24 AM Reply Quote 0
                      • G
                        george1421 Moderator @Tom Elliott
                        last edited by Dec 2, 2015, 3:21 AM

                        @Tom-Elliott I got sucked into fixing a downed business system tonight, so I haven’t had a chance to test this new build out. But while I was working on the outage I started thinking about this new setting. When you upload an image in the new environment, does it come in published or unpublished (may not be the correct term)? If it comes in published, then depending on the replicator cycle I have no more than 10 minutes (probably less depending on where the replicator is in its cycle) to unpublish it before the replicator. Once the replicator starts sending the file then unpublishing it after the fact is a bit moot. I just want to confirm that when an image is captured it enters the system in as unpublished. It will be up to the FOG admins to publish the image for replication. I can see that we would still want local deployment of the image, we would just want to kill replication of the images and snapins until they are published. (hopefully I didn’t make that too confusing)

                        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!

                        W T 2 Replies Last reply Dec 2, 2015, 3:25 AM Reply Quote 1
                        • G
                          george1421 Moderator @Wayne Workman
                          last edited by Dec 2, 2015, 3:24 AM

                          @Wayne-Workman I can see it working as you have defined it too. For my specific case, I might want to deploy the image at HQ but not send it to the remote sites until it has been qualified and approved. My specific goal would be to conserve WAN bandwidth. But I also don’t want to make too many exceptions because then programming becomes crazy for every one off condition.

                          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
                          • W
                            Wayne Workman @george1421
                            last edited by Wayne Workman Dec 1, 2015, 9:25 PM Dec 2, 2015, 3:25 AM

                            @george1421 I agree. Default should be “Replication - disabled/unchecked”

                            FOG Users - when they see that checkbox, they will immediately know what it does. So no worries of confusion.

                            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
                            • T
                              Tom Elliott @george1421
                              last edited by Dec 2, 2015, 3:32 AM

                              @george1421 you have to create the definition first, right? The checkbox for replicate is there and on by default. However you can tell it not to be replicate by Unchecking the box.

                              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

                              G 1 Reply Last reply Dec 2, 2015, 3:38 AM Reply Quote 1
                              • G
                                george1421 Moderator @Tom Elliott
                                last edited by Dec 2, 2015, 3:38 AM

                                @Tom-Elliott Ok that’s right I have to create the definition first. So I’ll have the chance to turn it off. The day has been too long and the brain cells have already gone to bed. This sounds exactly spot on. I’ll give it a go in the AM. Thanks.

                                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
                                • W
                                  Wayne Workman
                                  last edited by Dec 2, 2015, 6:58 PM

                                  Solved this thread.

                                  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 0
                                  • 1 / 1
                                  1 / 1
                                  • First post
                                    14/20
                                    Last post

                                  162

                                  Online

                                  12.0k

                                  Users

                                  17.3k

                                  Topics

                                  155.2k

                                  Posts
                                  Copyright © 2012-2024 FOG Project