Posts made by Wayne Workman

https://github.com/FOGProject/fogproject/pull/409/files
https://github.com/FOGProject/fogproject/pull/410/files

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.

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>

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

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

good point… I suggest we look at both locations and send the one from the file with a newer timestamp.

Or maybe there is a better way?

Fixed: http://fog-external-reporting-results.theworkmans.us/

Here is my first pass at the presentation layer: http://fog-external-reporting-results.theworkmans.us

The graphs/files/stats automatically are updated every hour. I think the graphs could use color adjustments, but overall I’m pretty satisfied. What do you all think? BTW, the data in here is real!

The next phase of this is abuse detection for the data reported. I need to scan for profanity, insults, etc; to keep the graphs clean. Python has tools for all of that.

agree with Sebastian. Just link to the old video. When it dies, it dies.

Has anyone tried out Coreboot? https://www.coreboot.org/

It appears to have ipxe and uefi support. I’m thinking about installing it on an older laptop I have just to play around with it.

@JJ-Fullmer can they be converted to something YouTube supports? (as opposed to re-recording)

We can put them on the FOG Project Videos YouTube channel. https://www.youtube.com/channel/UCrvOQPcm1SDIfIrzWZ9K3bA/videos

How exciting, entries! A whole lot of Ubuntu, one of them is Ubuntu 16!

He also messaged me. I suggested to use the community utility script that updates everything with the new IP:
https://github.com/FOGProject/fog-community-scripts/tree/master/updateIP

@Sebastian-Roth said in Feature request for FOG 1.6.x - Scheduled database maintenance:

maybe just provide a button in FOG settings for small and major cleanup instead of a cron task?!

I disagree about this being a button. There is stuff that gets into a funky state in the database because there are no relationships enforced, thus allowing code to get written without needed checks and/or bad logic. Absent of fixing those issues, the database will get messed up and a cron job really is needed to keep things working.

The items can be dumped out somewhere to be viewed sure, but this funk in the database literally breaks functionality, preventing FOG from doing what it’s supposed to do.

I should add I’m not talking about history. I’m referring to the issues that literally break fog. This stuff:

# The following chunk of commands will clean out most problems and are safe:
DELETE FROM `hosts` WHERE `hostID` = '0';
DELETE FROM `hostMAC` WHERE hmID = '0' OR `hmHostID` = '0';
DELETE FROM `groupMembers` WHERE `gmID` = '0' OR `gmHostID` = '0' OR `gmGroupID` = '0';
DELETE FROM `snapinGroupAssoc` WHERE `sgaID` = '0' OR `sgaSnapinID` = '0' OR `sgaStorageGroupID` = '0';
DELETE from `snapinAssoc` WHERE `saID` = '0' OR `saHostID` = '0' OR `saSnapinID` = '0';
DELETE FROM `hosts` WHERE `hostID` NOT IN (SELECT `hmHostID` FROM `hostMAC` WHERE `hmPrimary` = '1');
DELETE FROM `hosts` WHERE `hostID` NOT IN (SELECT `hmHostID` FROM `hostMAC`);
DELETE FROM `hostMAC` WHERE `hmhostID` NOT IN (SELECT `hostID` FROM `hosts`);
DELETE FROM `snapinAssoc` WHERE `saHostID` NOT IN (SELECT `hostID` FROM `hosts`);
DELETE FROM `groupMembers` WHERE `gmHostID` NOT IN (SELECT `hostID` FROM `hosts`);
DELETE FROM `tasks` WHERE `taskStateID` IN ("1","2","3");
DELETE FROM `snapinTasks` WHERE `stState` in ("1","2","3");
TRUNCATE TABLE multicastSessions; 
TRUNCATE TABLE multicastSessionsAssoc; 
DELETE FROM tasks WHERE taskTypeId=8;

https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_MySQL#Database_Maintenance_Commands

A button for clearing just the history table is a good idea though.

@Tom-Elliott Good thoughts about not focusing on bash scripts. My thoughts on this…

At work, if you can point your peers to documentation saying “this project only supports this distribution” Generally your peers accept it.

It’s been a topic that has come up before: Dropping installer support down to one or two distributions. CentOS and/or Debian. This probably deserves another forums topic.

At this point, I think supporting one distribution is best. I don’t care which one it is, though Debian probably has the best shot at longevity. I fear CentOS will slowly become irrelevant to many as Red Hat focuses on supporting IBM (their parent company), giving less focus to everything else.

@george1421 said in Feature request for FOG 1.6.x - Replace NFSv3:

AESNI requires the CPU to support this and not all of them do. Some of the enterprise intel CPUs do, but not all. I think it would be risky to rely on AESNI in the cpu support.

If the person doing the imaging wants to use encryption, perhaps FOS can detect if AESNI is supported and if so, use it. Otherwise fall back to something else that still provides encryption but might be slower.

@Sebastian-Roth said in Feature request for FOG 1.6.x - Replace NFSv3:

Do we want the network traffic to be encrypted or not? Do we want the client to do authentication?

If it’s not too hard, I’d say make it optional. Things are going to perform faster without encryption and encryption doesn’t make sense in all scenarios. Consider off-line imaging on a disconnected network, or a tech working for a school trying to get thousands of systems imaged in a limited amount of time using an already secure network.

At one point @Joe-Schmitt had shared a google doc and several people assisted outlining some documentation there. I can probably dig up the link.

I guess we should know what ought to go into the new documentation. It’s easy to get carried away with all the details concerning Linux and all the open-source components that make up fog. We should control scope for the first effort, keeping the scope small.

I might suggest adding some installation guides - many are already created in the wiki (some even have videos).

A section on DHCP and ProxyDHCP - keeping it lightweight, just what you need to do to get going in the most common scenarios.

I’d suggest a beginners guide to imaging. How to capture an image, how to deploy an image.

Talk about the FOG Client, how to use it for domain joining.

Past that, we can add to it as we need. Small steps.

Today, RHEL 7 & 8 failed all tests, both for patching and FOG installation, for every branch (so three times in a row). Looks like RHEL repository mirrors are unavailable. Bad day for Red-Hat it seems.

Red Hat Update Infrastructure 3 Client Configur 0.0  B/s |   0  B     06:00    
Errors during downloading metadata for repository 'rhui-client-config-server-8':
  - Curl error (28): Timeout was reached for https://rhui3.us-east-1.aws.ce.redhat.com/pulp/mirror/protected/rhui-client-config/rhel/server/8/x86_64/os [Connection timed out after 30000 milliseconds]
  - Curl error (28): Timeout was reached for https://rhui3.us-east-1.aws.ce.redhat.com/pulp/mirror/protected/rhui-client-config/rhel/server/8/x86_64/os [Connection timed out after 30001 milliseconds]
Error: Failed to download metadata for repo 'rhui-client-config-server-8': Cannot prepare internal mirrorlist: Curl error (28): Timeout was reached for https://rhui3.us-east-1.aws.ce.redhat.com/pulp/mirror/protected/rhui-client-config/rhel/server/8/x86_64/os [Connection timed out after 30001 milliseconds]

Here’s the benefits I can think of for keeping them together.

• a certain version of the documentation is locked together with the corresponding code it’s documenting.
• When you checkout an older version of fog, you’re also checking out the older corresponding documentation, and if you’re checking out a newer fog, you’re checking out newer corresponding documentation.
• When comparing differences between an older version and newer one, it may be easier for some to see the changes by looking at the differences in documentation.