@Dominique check the /var/log/php-fpm/www-error.log
If I were to guess, you have lack of memory. Just a guess though.
@Fernando-Gietz Would you mind matching up working-1.6 schema.php and the working/dev-branch schema.php?
From what I can tell, the changes between 1.5.x and 1.6 schema won’t impact the 1.5.x much from what 1.6 is adding/changing. The only part I see a little concern is the FOG_USER_VALIDPASSCHARS as in 1.6 its switching to a regex pattern vs implicit keys.
Then make this db changes from 1.5 to 1.6 at least be common.
Also, the recommendation for the max-bitrate issue is it already exists and is based on the Master Storage Node’s bitrate setting. The rexmit-hello-interval should also be added based on the Master storage node (as opposed to global values.)
This is simply because the global value means EVERYTHING that does multicast will use the same rexmit and bitrate settings. Having it per master storage node makes this much more dynamic and site specific.
I’ve added a globalized switch for allowing the admins to have the eye display/hide the password. By default the schema will set the “Enabling” to on (which is the current functionality.)
Unfortunately, I don’t know if this can be brought into 1.5.x
Not because we couldn’t add it, but because of the divergence between 1.5.x and 1.6
I’ve added the code to 1.6 base code however and tested that it was working properly. Hopefully we can have a 1.6 pushed out relatively soon.
It would not be too difficult to add the
I’m pretty sure the
--max-bitrate can already be defined by setting the bitrate element of the storage node that will be handling the Multicast stream.
Adding addition commands would be useful is think, though we need a common mechanism in order to break out the extra commands. (E.G. comma separated list to break out into an array of additional commands)
Should these commands be per Master Storage Node, or global?
I’m leaning more towards per master storage node so each node can be configured independently (which is why we did the same thing for bitrate as bitrates would seem – to me – to be per node’s network capabilities.)
@george1421 I need to add,
. is NOT just a way of saying run, it’s also a shorthand way of sourcing the file, the same as:
Basically, source means to bring the file in, similar to requiring other files in order to access different variables/functions that you may want separated from the purpose of the main running script.
The persistent groups plugin is most likely still working.
First, understand how it works.
It’s a simple trigger that’s generated but the trigger gets it’s template from a default host assigned to that group.
The template host name must be the same of the group’s name. In that host, you define your wanted group settings. Then, when you add a “real” host to the group, it will obtain the information in that group.
This encrypted form of the password has since been removed.
There’s multiple reasons for this, and the quickest reasoning was the encrypted form of the password contained both the IV and Passcode used to decrypt it in the first place. It looked confusing, but ultimately it had no better security than being in plain text. That and it added complexity to the base code, by having to encrypt, and before sending to the fog client being decrypted and reencrypted.
As the data is passed only between the client and the server in an encrypted format of which the encryption password changes every 30 minutes, having it encrypt->decrypt->encrypt didn’t add any value either.
This is intentional.