Get webdestdir and symlink right or even rid of the later


  • Senior Developer

    As we have seen in the first round of running the new FOG reporting there still seem to be a fair amount of installs out there with somehow messed up web directories.

    Let’s try to collect the evidence here and find a fix for that. Not saying that we should auto-fix this in the scripts but get a good detection in place and warn people so they can read the docs to fix this.

    I have looked through the repo and I am fairly sure RHEL/CentOS always used /var/www/html as docroot and we set webdirdest to /var/www/html/fog accordingly.

    Not that easy with Ubuntu and Debian. The installer used /var/wwwfor docroot and webdirdest therefore /var/www/fog. Soon enough another varibale was introduced for /var/www/html - possibly because Debian was different than Ubuntu. There are a lot of commits in 2015 trying to get this right and I assume that the Apache package we used from an external repo at some point added to that dilemma as well.

    The more I look at this the less I understand why links where used in the first place. @Tom-Elliott Do you remember more of the details and can you say why links were used?

    Edit: In the very old days we did not modify the Apache config at all and did have to behave according to what was given. Now since a long time we modify the Apache config. Plus Ubuntu, Debian and CentOS/RHEL all use /var/www/html today.





  • There are these two variables within fogsettings:

    docroot='/var/www/html/'
    webroot='/fog/'
    

    Why not respect them?
    Whatever docroot is set to, touch only that and stop touching other web directories period.

    Because what business does the installer have making symlinks in directories that are not defined within /opt/fog/.fogsettings?

    Also, I think the fog reporting should source the /opt/fog/.fogsettings file and use something like this to determine the correct file to get the version from:

    source /opt/fog/.fogsettings
    config_file=${docroot}/${webroot}/lib/fog/system.class.php
    fog_version=$(cat ${config_file} | grep FOG_VERSION | cut -d',' -f2 | cut -d"'" -f2)
    

    Concerning systems out there with the old web directories, I really don’t see an issue with just leaving it as-is. I know @Sebastian-Roth said it could be problematic when manually updating kernels - but the web UI has a kernel update feature, and anyone digging into the docroot guts probably can figure this stuff out for themselves or come here and ask for help.


  • Senior Developer

    @george1421 @Wayne-Workman Sure moving the web UI to a new standard location would be an option but I would not so this without a really good reason and I don’t see that here.

    As mentioned Debian, Ubuntu, CentOS and RHEL use /var/www/html as docroot since some years and I have used that when posting in the forums and such for all that time now. All that would be wrong if we switch to /opt now.

    Right, detecting the issue should be as simple as running diff on those system.class.php files or even more save diff the whole directories. Should be fairly quick and return empty if there link is fine.



  • The new external reporting server-side also runs it’s API out of /opt. Link here. This is a snippit of the conf file:

    <VirtualHost *:443>
        ServerName fog-external-reporting-entries.theworkmans.us
        WSGIScriptAlias / /opt/external_reporting/wsgi.py
        <Directory /opt/external_reporting>
            Require all granted
            AllowOverride None
            Options None
            Order deny,allow
            Allow from all
        </Directory>
    </VirtualHost>
    

  • Moderator

    @Tom-Elliott said in Get webdestdir and symlink right or even rid of the later:

    So Debian based usually just get put in /var/www and red hat gets put in /var/www/html. The. I put a symlink where needed to make getting to them in either place on any OS similar.

    From a support standpoint, we really need one path to give to the user for debugging purposes. It would be too much to say if you have OS W use this path and OS Z use this path. Another option would be to move the FOG web ui code out of the docbase directory altogether much like xibo does.

    Xibo places its php code in /opt/xibo-cms, then drops this file into the Apache’s conf.d directory.

    ]# cat xibo.conf
    Alias /xibo "/opt/xibo-cms/web"
    
    <Directory "/opt/xibo-cms/web">
        AllowOverride All
        Options Indexes FollowSymLinks MultiViews
        Order allow,deny
        Allow from all
        Require all granted
    </Directory>
    

    Of course for selinux this directory and its files needs to be tagged correctly. But its an option.



  • So, how would one manually check for this problem? Simply looking in these two spots? Is that it?

    • /var/www/fog/lib/fog/system.class.php
    • /var/www/html/fog/lib/fog/system.class.php

  • Senior Developer

    @Sebastian-Roth the red hat method has always done /var/www/html/fog

    So the folder always is there. For some semblance of similarity between red hat and Debian, on red hat I create a symlink from /var/www/html/fog to /var/www/fog

    On Debian based, up to around 1.3.x the web instal was set to /var/www/fog.

    When Debian moved to using html, subsequent fog updates needed to go to the new location as well.

    To ease the process, we still put the main data at /var/www/fog and created a symlink into /var/www/html/fog.

    So Debian based usually just get put in /var/www and red hat gets put in /var/www/html. The. I put a symlink where needed to make getting to them in either place on any OS similar.


  • Senior Developer

    @Tom-Elliott I don’t get what you mean. Could explain it a different way?

    @Wayne-Workman On daily life it’s not making much of a difference but if you do a manual kernel update or things like that you can run into an issue easily.


  • Senior Developer

    The reason Debian and Ubuntu get a symlink into /var/www/html/fog is for the same exact reason as old installs having been upgraded. The older may have only been /var/www/fog but with an upgrade.



  • What problems could there be if a system has an old fog version in an old directory?


Log in to reply
 

308
Online

7.5k
Users

14.6k
Topics

137.6k
Posts