• Recent
    • Unsolved
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Register
    • Login
    1. Home
    2. aborn
    3. Topics
    A
    • Profile
    • Following 0
    • Followers 0
    • Topics 2
    • Posts 10
    • Best 0
    • Controversial 0
    • Groups 0

    Topics created by aborn

    • A

      Unsolved Updating database Failed Error returned: <!DOCTYPE HTML PUBLIC .... 503 Service unavailable ....

      FOG Problems
      • • • aborn
      5
      0
      Votes
      5
      Posts
      647
      Views

      R

      @aborn

      Good day.

      Did you get any resolution for this problem?

      I have Fog 1.5.7 on CentOS 7 with the specified partition sizes. All other settings as default, firewall and SELinux are disabled. My image name is W10E.

      I get the same results as you did, also with the image files appearing in the /images/dev folder, then in /images/W10E and then disappearing again.

      I sort of got around it by copying the /W10E folder to /W10E (copy), wait for /W10E to disappear and then rename the copy as /W10E. And I can deploy this image, absolutely no problem.

      Many thanks
      rarcher2

    • A

      Unsolved Images are created with 777 (world writable file rights) and owner root on CentOS 7

      Linux Problems
      • • • aborn
      16
      0
      Votes
      16
      Posts
      1.2k
      Views

      george1421G

      @aborn said in Images are created with 777 (world writable file rights) and owner root on CentOS 7:

      I inserted the proposed new line now in the fog.postinit script

      This is at the wrong point in time. We can use a postinit script to fix things before things happen. Current a postdeploy script will handle actions after an image is install on the target computer. What we need is a postcapture script to handle things after the image has been captured but before the image is moved from /images/dev to /images. Once the image has been captured we will use a postcapture script to reset the permissions and file ownership of the captured directory so that the FTP process can move it as fog. I can see the process in my head clearly. We just need to patch the fog.capture (guessing at name) script to make the call to a postcapture script. We should be able to mimic what is done for a postdeploy script. It shouldn’t be that hard to do, then we’ll use a postinit script to copy the patch fog.capture script to FOS before it starts doing its thing.

    • 1 / 1