Because Cloudlinux fails to support Directadmin we are going to say goodbye

[iseletsk]

1. Integration is much harder then with any other control panel. If it wouldn be for Martynas - it would took us weeks of dedicated work to figure out how to do it right, and even then it would take a long process of trial and error to actually get it right.
Martynas was kind enough to integrate our patches into custombuild. Without it -- it wouldn be trivial at all. For the other control panels we either ship Apache as RPM, or they have a very simple way to setup post/pre-build hooks.
Without Martynas - we would be having exactly the issue you are describing -- where upgrades of DA would cause our changes to apache to be wiped out, or our changes would have had a chance to clash with DA.

Regarding MySQL -- we are ending up not to push it into custombuild, but instead disable MySQL updates via custombuild and update ours from our repository. From what I got -- this is default way to install custom MySQL on DA. And yes -- we plan to add MariaDB into our repositories as well.

[smajor]

> Igor Seletskiy wrote:
> 1. Integration is much harder then with any other control panel. If it wouldn be for Martynas - it would took us weeks of dedicated work to figure out how to do it right, and even then it would take a long process of trial and error to actually get it right.
>
> Martynas was kind enough to integrate our patches into custombuild. Without it -- it wouldn be trivial at all. For the other control panels we either ship Apache as RPM, or they have a very simple way to setup post/pre-build hooks.

You could ship as RPM with Directadmin as well

> Without Martynas - we would be having exactly the issue you are describing -- where upgrades of DA would cause our changes to apache to be wiped out, or our changes would have had a chance to clash with DA.

This is not true... unlike other control panels upgrading directadmin does not upgrade software on server, it doesnt change software versions otherwise you could not install your own versions. Think of directadmin just as a configuration file editor, it reads what is stored in a configuration file, presents it to the user in a GUI, lets the user make changes then writes those changes to disk... so you can edit files on disk in nano or vi or you can edit them in directadmin. Directadmin really has no sense or idea of what software versions are installed nor does it care, it is simply a config file editor.

> Regarding MySQL -- we are ending up not to push it into custombuild, but instead disable MySQL updates via custombuild and update ours from our repository. From what I got -- this is default way to install custom MySQL on DA. And yes -- we plan to add MariaDB into our repositories as well.

Absolutely and anything else for that matter could be the same. Let me give you an example:

CustomBuild is just a fancy script for installing software that martynas cooked up... I can write one or you could write one just the same.

Martynas chooses not to include suhosin into php, so I dont use custombuild to install php, also I use litespeed web server so I do not want apache running on my system... so I dont use custombuild to install apache either.

So I install litespeed, and I install php with litespeed lsapi and suhosin and a couple others like exec_dir patch

Now directadmin released their next update... I do want the latest version of DirectAdmin so I can either click update directadmin in the DA control panel and directadmin gets updated but no software on my system changes, or I can use martynas script and run command ./build directadmin same effect directadmin does not overwrite any changes I have done

now lets say I want to install the RPM you have made available for apache... I simply un-install apache and run "yum install httpd" then your version of apache is installed not directadmins not martynas version but yours.

As long as your RPM uses the same configuration file paths that directadmin looks for them in, then there is no reason we cannot use your rpms

You can do same for mysql, exim, php, proftpd... and so on

no hooks needed, no overwrites as you say, just plain old vanilla yum install... like I said before picture Directadmin as if it was a server that had no control panel at all.

Hopefully with this you will understand the picture better... because saying integration is harder with directadmin is like saying integration is harder with a plain install of CloudLinux that doesnt have a control panel installed on it.

You dont need to hook you just need to install your version that uses the same configuration file paths as directadmin looks for them in.

[smajor]

Does that make the picture more clear?

its just like when you release mariadb rpm... we can un-install mysql and run yum install mariadb given that you have made the rpm use the same paths for configuration files as directadmin looks for them in.

martiynas script really only does that... but he added a bunch of extra functionality in there but there is no reason you couldnt do the same with your own script... for instance if we wanted to upgrade to the new mysql version martynas script before upgrading backs up the databases in case something goes wrong.

it really is that he wrote a script that does what you or I could do via rpms or source for that matter.

Directadmin will never overwrite your changes or change sofftware versions it wasnt designed to do that... and it wasnt designed to care either so install what you need and forget about "integration" per say cause there is no integration just you making compatible rpms

[smajor]

See for yourself mysql and a few others are no more than rpms http://files.directadmin.com/services/es_5.0_64/

thats under centos 5 64bit folder

martynas builds apache from source, I think he might bake in a few mods like securelinks protection, you would have to ask him about those then add them to your rpm

http://files.directadmin.com/services/custombuild/

for php you dont need martynas version create an rpm of your own... personally we use litespeed so we have to compile our own from source

then there would be no reason we couldnt use yum update from your repo.

Directadmin wont freak out if you do create your own rpms because directadmin doesnt care nor should it... this allows you to release timely updates, bugfixes, security patches... all without breaking directadmin... try to do that with cpanel or plesk

This also allows us as admins to respond to 0 Day exploits and quickly update our servers to the latest patches without waiting on directadmin to release them unlike other control panels.

See as soon as cloudlinux releases an update we can run yum update and we are up to date and dont have to wait on martynas or directadmin.

Does all of this make more sense now?

[smajor]

We also are not limited to vendor specific rpms, obviously this is not the case with cloudlinux if one wants the integration we would have to wait for you to release security patches to software via yum.

But for instance on CentOS 4 with directadmin... the centos repos only allow bind 8.4 but we want bind 9.x so we upgrade to bind 9 ... guess what directadmin doesnt care it wont break it nor will it overwrite it when upgrading directadmin.

The above statement might not be true for os compatiblity I dont know, I was just using it as an example. versions might not make sense.

or say I want PHP 5.4 and martynas is only up to 5.1 .... I can install php 5.4 via yum or source... heres the kicker if I want php that works with cloudlinux obviously I get to only use cloudlinux rpm unless you guys provide a upgrade script of your own so we can custom compile it with our own modules.

you can write upgrade scripts of your own as well they dont need to be rpms if you want it to be flexible for us to be able to compile from source... this way we can continue to stay up to date with the latest patches and versions of php, mysql and apache

you dont have to use custombuild in otherwords do it yourself as if there was no control panel on the system...

[smajor]

please dont take my responses to your post the wrong way, I am just trying to make sure you understand the way it works so you can best decide what is not only going to be the best way for you to handle upgrades but also what will still allow us the flexibility to include our own modules with your patches in software like php.

obviously you providing your patches in a php rpm would limit anyone from upgrading php to the latest security patches or version and would make it difficult for us to include stuff like suhosin patch or exec_dir patch...

so use your imagination create your own upgrade script for just the packages you maintain like php, mysql, mariadb which allow us to hook into and add stuff like suhosin and exec_dir patch or litespeed php lsapi

for your packages directadmin users can use your upgrade script and for the rest they can use martynas or their own.

[smajor]

patiently awaiting your response

[iseletsk]

The thing is that this flexibility makes it very difficult for us to create "automated" install.
We provide all the patches in open form, so you can apply it if you go after "roll your own" approach.
We also provide RPMs if you want to use RPMs

Yet, trying to detect, and automate depending on what you use is pretty impossible. We can handle custombuild (thanks for Martynas help)-- but we simply cannot handle "all" the cases in automated fashion.

[smajor]

I still think we are missing here... Why can you just create your own rpms for the mysql and apache and put them on your repo...

then in your documentation write something along the lines of: to install cloudlinux on directadmin, uninstall apache and mysql then run command yum install httpd mysqld

THen from then on out all a CL user has to do is run yum update

poof you are integrated and automated

[smajor]

for php create ssh script update_php.sh then we can run said php script to install php and your patches and add any additional patches if we need them.

poof php is automated

[smajor]

see there is it is the same as if we are working with a server that does not have a control panel if you think of it that way there really is nothing standing in your way... no detecting versions etc

it really is just that simple... I think you are over thinking the Directadmin control panel... probably because you are so used to control panels that "Control" the system

[iseletsk]

We have MySQL and httpd in our repo:
yum install httpd
yum install mysql-server

We also have php & php5.3 -- it is all there.

[smajor]

Questions #1

> so the rpm in the repo uses the same configuration file paths as directadmin?
>
> /etc/httpd/conf/httpd.conf
>
> /etc/my.cnf
> /usr/local/mysql/

Question #2

> I see you only have php 5.3 where as php 5.3.13 has been release as well as php 5.4.3
>
> maybe like I was saying you write a shell script that will install php with your patches and we can add our own configure lines and add our own modules and patches... you know make it easy for people to be able to install what their requirements for their server are.

[iseletsk]

Our version of PHP is based on RHEL php.