Zend, ioncube and opcache seem to be gone?

ju5t

Verified User
Joined
Sep 14, 2005
Messages
409
Location
Amsterdam
Are zend, ioncube and opcache removed from CustomBuild?

Running ./build set returns:

zend is not a valid option.
ioncube is not a valid option.
opcache is not a valid option.

Running version:

# ./build version
2.0.0 (rev: 2425)

OS: CentOS 7
PHP1: 7.3
PHP2: 7.2

Running FPM + Apache.
 
You can find them in php_extensions.conf:

Code:
cd /usr/local/directadmin/custombuild
cat  php_extensions.conf

I believe you can change the option only manually now. Sure, they will fix it soon.
 
@smtalk, you should fix this so that it is bakward compatible with previous setting. Feel like loosing some control here now. :(
It's backwards compatible rev. <2426 just thrown this additionally, even if the option was set. Fixed rev. 2426 to suppress it.
 
Thanks for the update. I fully agree with @ditto. We still have to make changes to our configuration management though. The php_extensions thing breaks it as our checks are based on options.conf.

Would it be possible to use semantic versioning in the future? Using revisions for all versions are not very 2020 if you would ask me :).
 
Thanks for the update. I fully agree with @ditto. We still have to make changes to our configuration management though. The php_extensions thing breaks it as our checks are based on options.conf.

Would it be possible to use semantic versioning in the future? Using revisions for all versions are not very 2020 if you would ask me :).
If you configure them in options.conf - they should still work, and be moved to php_extensions.conf automatically.

Regarding versioning - version increasement would have been done anyway, and changelog filled. However, if you have suggestions for the versioning - they're welcome.
 
We use semantic versioning https://semver.org/. CustomBuild kind of does too. But the current version is 2.0.0 but minor and patch versions are never updated. This makes it hard to predict if a new version introduces new features or patches.

If you configure them in options.conf - they should still work, and be moved to php_extensions.conf automatically.

As CB doesn't have a way of checking if an option is set or not, our configuration management checks if the option exists in options.conf and if the value matches what it expects, if it doesn't, it corrects it. This is happening every 30 minutes on all servers because they have moved..

I do realise that grep is a poor solution. It would help if CB had a way to check the current setting from a command line tool. Unfortunately, ./build options doesn't have great output so you would still have to grep for output.

We can change our current grep command to include php_extensions.conf but it still isn't great. Changes like this make it harder and harder to control DirectAdmin at larger scale.

I understand that CB can't stay as it is forever and I am very happy with all the features it offers, but I don't like coming in the office on a Monday morning with our configuration management complaining (apparently it had updated this morning by itself?).

What do you suggest? Stick with grep or have I missed a hidden gem in the current CB release to check for settings?
 
The following can be used:
Code:
./build show_file options
./build show_file php_extensions

I could add ./build show_file options_combined to print both of them, but.. we could have imap=yes for something in options.conf in the future, and imap=yes in php_extensions.conf, they'd have the same name, while actually they'd be in different files :)
 
That's pretty much the same as grep'ing on those files. It would still error out in this case.

What is the plan for future development of CB? How are we supposed to manage php_extensions.conf in the future? Will it be through ./build set or will there be a new command for it? Or are options going to be prefixed with php_ for example?
 
It’s “./build set_php”, but old extensions are backwards compatible with “set”, so old tutorials still work.
 
Right, I think we'll just rework our current implementation to support both 'set' and 'set_php' and check the files both manage as we are doing at the moment with. I don't think having combined output of show_file is a solution in the long run and I'm guessing 'new' extensions will not be backwards compatible with 'set', so we need a solution either way. Using show_file and grep its output doesn't make much of a difference to us, unless you're planning on moving options.conf, which I don't think you will.

I would be very grateful if CB could use an improved versioning schema though. Semver is pretty common and easy to work with too.
 
I came here because I had the same "surprise" when my ansible playbook was running. Thanks for clearing up what happened. I have some follow-up questions:

Which of ./build php, ./build all, and ./build update_versions (if any) will automatically run ./build php_extensions?

Does this impact in any way custom configure scripts/commands that are kept in e.g. /usr/local/directadmin/custombuild/custom/fpm/configure.php73?
 
@kristian: all of those :) ./build update_versions - only if not installed.

No impact for custom configure scripts. And old extensions should still work the old way, like ./build set opcache yes; ./build opcache

Not sure why ansible was having issues if you've used those?
 
Ansible didn't have issues as such, just that I maintain the contents of options.conf using a template, and it then triggered changes in the file, because ./build update had updated it. I always run against a dev server first though, for these reasons. :)

Thanks for clarifying!
 
Back
Top