HTTP Redirects After Upgrade 1.5.2 to 1.5.3

  • FOG 1.5.3
    CentOS 7.5.1803

    Did the upgrade via git. Seemingly everything went ok.

    I now realized I lost my symlinks in the /var/www/html/fog directory. So what I had done is place a directory in tftpboot called ‘os’. In this I placed sub-directories for each OS’s installation files. I also have a folder /pxeshare which is a samba share, in which I have a folder for ISO’s and scripts, /pxeshare/isos and /pxeshare/scripts.

    I wanted these to also be available via http but to not duplicate the information, so i used ln -s to create sym links within /var/www/html/fog to each of those folders. IE:


    This enabled me to access these via url/fog/os for example in the browser and/or my iPXE menu entries/installations via http.

    After the update these symlinks were deleted. No big deal I went back and created them again. Confirmed that httpd is running, confirmed my firewall-cmd rules are still in place, restarted the httpd service, reloaded the fire wall, confirmed/set SELinux to permissive and have even rebooted multiple times.

    When I try to navigate to url/fog/os now, it instead redirects me back to url/fog/management/index.php.

    I have glanced over my httpd.conf and nothing stands out as being something I had to alter before. Did something change in the way FOG works with http to cause it to redirect like this?

    I am sure I am missing something silly, I just cant see it. I will keep digging but any insight into resolving this would be great. Worst comes to worst I may simply roll back to a snapshot prior to the update and check more conf files to see if I did alter something to make this work.


  • @quazz Alright that appears to work. symlinks in /var/www/html are working. Thank you!

    @quazz said in HTTP Redirects After Upgrade 1.5.2 to 1.5.3:

    @zer0cool I think it will redirect anything with url/fog so try going one directory higher.

    Since I appear to be unable to mark moderators responses as the solution I have quoted your solution and will mark this solved. Thanks!

  • @quazz Ah ok I will give that a shot. Rolling back to my snapshot of 1.5.3 now, ill give it a shot and report back. Thanks

  • Moderator

  • @quazz Not sure I follow,

    In 1.5.2: - works

    in 1.5.3: - redirects to management

    Are you saying add an additional folder or remove one?


  • Moderator

    @zer0cool I think it will redirect anything with url/fog so try going one directory higher.

  • @quazz Yea I took a peak at that change and figured it may be it. However, Apache should be able to find these directories, so I am not sure why it redirects.

    I cant find any reason that the 3 folders I symlinked to wouldnt be seen by Apache and be valid. Just for kicks I put gibberish after url/fog and got the exact same result as when trying to get to one of my valid urls (symlinks).

    I just cant put my finger on the missing piece here. Its not SELinux, nor firewall. I reverted to 1.5.2 (from snapshot) and permissions are the same. It doesnt appear I altered the httpd.conf or any other httpd related conf file to make this work in 1.5.2.

    In 1.5.2 it seems it was as simple as create symlinks, SELinux = permissive, firewall allowing http, restarting httpd and good to go. In 1.5.3 it would seem something in the confgs like the change you point out has caused a problem in which my symlinks are not able to be followed causing it to redirect.

    For me its kind of a big deal as all of my iPXE stuff is using http, specifically these symlinks (as http is much faster than tftp in my testing). Without it working I would have to spend hours re-doing my menus, config files, etc.

    I can stay on 1.5.2 for now, but thats not a long term fix. Any help would be great. Thanks

  • Moderator

    Probably these changes to Apache configuration.

    As far as I understand, if the file or directory isn’t found by Apache it will redirect to fog/api/index.php
    (which will redirect to fog/management/index.php if it’s not an API request afaik)

    Make sure ownership and permissions match the other folders (check with something like ls -la)

    It seems like a lot of requests are getting 302 redirected, not sure if that’s intentional.

Log in to reply