It is not "./build rewrite_confs". It's a part of it. The part which rewrites user configuration files.how to put a ./build rewrite_confs into a task queue.
Code:
echo "action=rewrite&value=httpd" >> /usr/local/directadmin/data/task.queue
It is not "./build rewrite_confs". It's a part of it. The part which rewrites user configuration files.how to put a ./build rewrite_confs into a task queue.
echo "action=rewrite&value=httpd" >> /usr/local/directadmin/data/task.queue
It's better to teach customers they need to go with their time and upgrade their stuff. Same for appliation developpers. You can choose to keep old applications and old OS systems, as long as you also accept the fact that it will be unsupported at a certain point and keep running them are at your own risk.However, we have various reasons we need to keep old applications.
I think the best option would have been on centos6 servers to not have let custombuild update to newer versions that aren't compatible. This way there would be no need for additional delevopment but centos6 servers would still be able to reinstall software that's already installed on the server.There isn't much to add to the topic. Similar issues appeared when CentOS 4 or CentOS 5 could not compile packages anymore. New installations of CentOS 6 do not work for a long time already. Existing installations are still running. If we continue providing CustomBuild for EOL systems - it'll just start breaking the things, instead of leaving everything "in-place" and working. For example, latest version of CustomBuild has no support for init.d systems anymore, it's systemd-only. It has no startup scripts for the services, expects components like MariaDB or PHP to always be started in foreground mode, has no component-downgrades or code to custom-compile libraries that are available on newer systems. This error thrown is added there to protect the systems from unexpected behaviour-outages, not to cause them![]()
@smtalk perhaps you would be able to let users downgrade to this rev? This would make custombuild a whole more user friendly. I mean in this way you wouldn't break any functions that still require prior to migrations. Moreover in future cases of EOL OS users will give them the same possibilities. Win - win for everyone.I believe Cb. Rev.2923 / before 2930
its a last work for centos 6
But dont know how to change specific rev version?
#smart #idea@smtalk perhaps you would be able to let users downgrade to this rev? This would make custombuild a whole more user friendly. I mean in this way you wouldn't break any functions that still require prior to migrations. Moreover in future cases of EOL OS users will give them the same possibilities. Win - win for everyone.