Ignore the wifi mac from client operations?

I thought about adding this capability. It ultimately isn’t hard, but with trying to push toward a release, this is a bit overkill and would require a lot of testing to ensure all was working properly.

@Arrowhead-IT storage nodes now contain their own snapin path, and this is what is used for everything else, it’s only the cert finding that uses the implicit check.

Here’s a couple of quick and dirty txt files containing all the hook events, and their respective tie-ins for plugins or hooks for operationally using them.

I’m posting this because the AccessControl plugins uses these very emphatically to help with granularly controlling access. This, ultimately, means a full documentation of all the things that can be done natively.

One file is the “Core” events. These are the events that can be enacted upon and integrated directly with the “base” of FOG using no plugins. The other file is all the hooks that plugins also generate.

My hope is to get the access control plugin more on a dynamic nature than a guessing game. In the past I had tried documenting all the hook events into the database, and while this approach can work, it only inserts new entries when the event is to be processed in the first place.

What’s wrong with the above approach? Well, to limit constant read/write to the database, the hooks were only inserted into the database as they were spawned. So let’s just say, for example, you never visited the User page. Your hookEvent’s table would never contain any of the hooks that are available on the user page.

In these files, particularly the core file, is some commonalities between all pages I think. This will be evident just by looking at these files. A couple of places, however, use a generic approach to generate the event. These are using a % symbol to symbolize Host, Group, User, etc…

Some of these will also function for the Plugins too (just a note).

Hopefully this will help prepare people with some of our changes for when 1.6 is able to be published.

Hooks_And_Tie-ins.txt

Hooks_And_Tie-ins - Plugins.txt

@Wayne-Workman the group idea is currently, the host name that matches that of a group name will apply that matching host settings to any host that gets added.

The last group a host is inserted into (the latest group you added a host to) would define the host to have that new groups settings.

It’s basically your addition. Currently it only does this adding when and if a hostname matches the group name.

@Sebastian-Roth CentOS/RHEL get remi,remi-php56, DNF variants get remi only.

@sebastian-roth et al.

Sorry, I’ve not been able much to work on anything in a while. I will try to correct that moving forward though I’m still fairly busy with work and all.

I’m keen, if everybody else is, to look over 1.6 vs 1.5.x and just simply moving over to it. The UI for 1.5 was itself quite an overhaul but shows too little progress now (that we’re at 1.5.9). Moving to 1.5.10 seems cursory at this point, in my opinion.

I can’t say I’ll have a lot of cycles free to keep this moving in a linear fashion though.

The biggest hurdles with 1.5.x and 1.6.x are getting the codebase ready with PHP 8 support it seems too me.

I’m of course able to try to help release a 1.5.10 release if that’s what’s really needed, but I think the 1.6 codebase has been around long enough and in parallel long enough it might be a good position to just check the bases, clean up where necessary, and release 1.6.0.

Let me know what you all think.

@Wayne-Workman
Here’s how mine is setup:

Connection Name: What do you want to call it – not used for anything in regards to functionality.
Description: Self explanatory – not used for anything in regards to functionality.
Server Address: ###Needed### The address of your server.
Server Port: ###Needed### The port of your server (usually 389).
Search Base DN: ###Needed### The DN you need to search starting at… For me I’m searching under users common name.
Group Search DN: ###Needed### The dn you need to start searching for Groups… For me I’m searching under the OU named Groups.
Admin Group: ###Not required if mobile group is set### This is the group that will be looked at for ldap to be scanning for “FOG Admins”
Mobile Group: ###Not required if admin is set### This is the group that will be looked at to allow “mobile” users. These users cannot login to the main dashboard but they can login to the mobile page.
Initial Template: Does not do anything to the DB store. Just a “template” holder.
User Nam Attribute, what field to search for user names.
Group member attribute, what field to search for groups.
Bind DN, Not required as user based element should be able to find.
Bind Password the bind dn password.

Should be fixed, thanks for reporting.

I had the delete happening before checking if the prior replication was still running. Added a check to break out if it is already running.

To add on, however, we already check the filesystem during imaging.

@Quazz Found, confirmed, fixed, and pushed.

Thanks for reporting.

Working branch now has this added.

@kortnor The datetimezone issue should be fixed in the latest update. I wasn’t implicitly defining a Timezone, so it would not find any data in the case of a fresh install.

I found two places that I could use to ensure the timezone is set (albeit not necessarily accurate) in the case the DB hasn’t been loaded yet (fresh install), the php.ini file does not have a date.timezone specified (php defaults to commenting the timezone out). The fix, for now, is test the presence of the variable by means of checking if it’s empty or not.

Mind you if the php.ini file IS set with the date timezone setting, it will NOT try to use the one defined in the DB anyway. However, if you aren’t comfortable messing in /etc/php.ini, the current push of FOG should take over and operate as originally expected (no more 500 heres or erroneous error messages.)

imgFormat is how we determined Partclone VS. Partimage
from upgrading 0.32 -> current, image definitions are automatically associated with imgFormat of 1 (which equals partimage)
All I’ve done is extend the capability of this field
so the way it works now:
0 = partclone gzipped
1 = partimage (gzipped of course)
2 = partclone gzipped split 200MiB
3 = partclone uncompressed
4 = partclone uncompressed split 200mib
5 = zstd compressed
6 = zstd compressed split 200mib

@george1421 A + is perfectly fine in any path. Other special characters are perfectly fine as well, so long as they’re properly escaped. I know this is what you’re against, but it does already filter most other special characters, even as much as getting right of other weird special characters.

I want to say for people, using the zstdmt (vs pzstd as I can’t get it to build on 32 bit) the imaging is MUCH faster even at -19.

It’s compressing at about the same rate, more or less, but it’s much faster than the 35 minutes I originally had tested against. Using zstdmt on the same image with all cores in use took the 35 minute time and got it all done in 2 minutes 58 seconds.

@Wayne-Workman I’m already looking at it.

Because of what you reported, I’m working on a hopefully better approach to getting the dumped out file.

In as simple a word, No.

The plan, however, is to give the user the option to choose default of pigz/gzip or zstd, but PartImage will not have any “default” usage medium. This is because PartImage has not seen any developments and still considers NTFS “beta” implementation. While it “works” it’s not actively developed (from what I’ve seen) and has become quite antiquated.

Partclone will, for now, be the “goto” for capturing images. This is regardless of the compression medium as the compression system is totally independent of the partclone process.

I do plan to add the ability to let the user decide the “default” compression type, but as for the “default compression size” I think 6 is still viable. While it’s not the ‘mid level’ for the zstd compression mechanism, trying to “default” compression numbers between multiple compression types would become very messy to manage. The only reason the “default” was added in the past was because it was unsettable at the time and there had only been one compression choice.

@Sebastian-Roth I’ve looked into it and corrected it on my side. I have not pushed it so I can try to fix the db backup issue.

Default capture method is now in the “FOG Configuration Page->FOG Settings->General Settings category.”