@Sebastian-Roth said in Improve documentation:
I would see those three in the FAQ section, what do you think?
I think putting them in FAQ is fine, though the ones on fogsettings and password_central seem more like documentation that frequently asked questions. migrate_fog is more like a procedural thing. Though long as they get in there somewhere, it works.
If you look at the history on that one, it was added by “admin” in 2010 (probably by @Chuck-Syperski). I don’t remember seeing this article before.
When I was doing printers with fog (which works great last I used it), I just made a share on the Windows server to hold drivers, accessible anonymously.
This article is newer and better suited for creating samba shares: https://wiki.fogproject.org/wiki/index.php?title=Password_Protected_Samba_Share
I wrote that in 2016 when there wasn’t even RHEL 8/CentOS 8, but had foresight to add the correct commands.
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?
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.