Replacing Custombuild with yum

mkniskanen

Verified User
Joined
Sep 17, 2008
Messages
80
Location
Lieksa, Finland
Has anybody got rid of Custombuild updates for PHP. For me there are no pros, only cons to use Custombuild. The main problems are the long time it takes to compile a service and some weird out-of-memory crashes during the build process plus some problems I have encountered so far. I have been running Remi powered versions on non-DA servers and they work just fine without one single problem.

So if I drop PHP7.x (7.1 at the moment) and replace it, say with a Remi repository version, what are the possible caveats?

Some background info plus just one of the problems: I have an absolutely clean DA Centos 7 server with zero hacks installed. Everything is as pure DA as it can possibly be. Today I ran the standard

Code:
./build update php

and the result was that nobody could log into the admin interfaces requiring use of PHP sessions. The reason was /var/www/tmp which was owned by webapps.webapps with permissions 700 and the PHP user tinyshop.tinyshop had no way to store the session info. I have no idea why everything worked before but not after the update. Changing the permissions to 777 was the only quick way to stop the flow of telephone calls from customers.

I have no idea what, where and when did something weird but the above happened five minutes after I had updated PHP.
 
I think you're doing things wrongly. Custombuild is great when used in correct way.
It's not ./build update php but first ./build update and ./build update_versions after that. Or were you only updating php?
It's normal that /var/www is owned by webapps.webapps and should never get to 777 but I understand this was a quick fix.

It should look like this:
drwxrwx--- 2 webapps webapps 84K 2017-06-13 12:02 tmp
so chmod 770.

Maybe this is already of help.

About the other issues, I'm sure there is somebody who can explain this or help you with that, maybe Zeiter or SMTalk.
 
Richard,

I have done the "build update" first, of course and then simply updated the PHP versions I have. I cannot understand what could go wrong. I have used Custombuild for a long time in the past but ever since I converted my old servers to Nginx + php-fpm I only used DA for creating users and administering email settings, quotas and so forth.

The main problem is the horrible time it takes to compile the two PHP versions. As I said there are zero benefits compared to Remi repositories, for instance. A "yum update" has never failed so far. "build update php" has ended up in a low memory error a couple of times and needed another build cycle to finish the task. Yes, only 1 GB memory but that should be sufficient for such a simple task.

As for /var/www/tmp: as I wrote it was 700 initially (after DA installation or changed by DA at some point, possibly) and I have not touched the permissions. However, if I change it to 770 nothing will change because the users created by DA do NOT belong to group "webapps". A user "myshop" only belongs to group "myshop" initially and has no write access to the directory. That is why I had to chmod it to 777 as a quick fix. I could, of course, add all my users to group "webapps" but that should be done by DA when creating the user.

I frankly have no idea why DA is behaving like this. That is, however, how it was installed. Having noticed that the whole user/group system has changed totally since my previous installation 5+ years ago I decided not to make any changes to mess up things. DA, however, seems to mess up things for me. I now only have about a dozen users on that server and I think I will move them away from there one by one.

regards
Markku
 
Last edited:
Hello Markku.

What you are explaining now is quite a bit different compared to what you said before:
Everything is as pure DA as it can possibly be.
Well no... a pure default DA is not with nginx and not with 2 php versions enabled. ;)

And now you also say:
but ever since I converted my old servers to Nginx + php-fpm I only used DA for creating users and administering email settings, quotas and so forth.
Which is quite something else from a "pure DA as it possibly can be", or I'm misunderstanding something.

However it's an odd issue, but it could be caused by something which did not go well during this conversion. Especially since you stated yourself the problems started at that time.

I presume you're using custombuild 2.0. Could it be you used mod_ruid before? Is it disabled?

I just read another thread that with nginx it should look like this, not only webapps:
Code:
[root@server ~]# ll -d /var/www/html
drwxr-xr-x. 9 webapps webapps 4096 Oct 12 16:22 /var/www/html
[root@server ~]# ll -d /var/www/
dr-xr-x--x. 10 webapps nginx 4096 Dec 20  2014 /var/www/
[root@server ~]#

It looks however like indeed something else is going wrong when you got memory issues.
However, it feels like something went wrong during conversion and probably Zeiter can help you best with this, because he knows a lot about nginx and I don't.

Hope you can fix it!
 
What version of Custombuild are you using? 2.0? And I don't know if the commands:

Code:
./build update php
./build php

are the same? I have never heard of ./build update php, always ./build php, as it is described in the FAQ.
 
Hello Markku.

Well no... a pure default DA is not with nginx and not with 2 php versions enabled. ;)
However it's an odd issue, but it could be caused by something which did not go well during this conversion. Especially since you stated yourself the problems started at that time.

I presume you're using custombuild 2.0. Could it be you used mod_ruid before? Is it disabled?

Okay, lets correct that bit of response first. I have installed EVERYTHING using the tools provided by DA and Custombuild 2. I have not installed ANYTHING using other than those two. What is mod_ruid? Sounds like an Apache thing? I have not used Apache for more than five years anywhere. There has been no Apache on this server. It is A CLEAN INSTALLATION with Nginx, Php, MariaDB and the normal CB2 stuff (exim, dovecot, roundcube etc).

From custombuild.log:

Code:
2016-12-03 12:12:14 89.188.9.41: Nginx 1.10.1 installed
2016-12-03 12:12:17 89.188.9.41: jpegsrc.v6b.tar.gz installed
2016-12-03 12:12:40 89.188.9.41: libpng 1.6.26 installed
2016-12-03 12:12:57 89.188.9.41: mcrypt 2.5.8 installed
...
2016-12-03 12:12:35 89.188.9.41: libxml2 2.9.4 installed
2016-12-03 12:12:51 89.188.9.41: libxslt 1.1.29 installed
2016-12-03 12:12:46 89.188.9.41: PHP 7.1.0 installed
2016-12-03 12:12:21 89.188.9.41: PHP 5.6.28 installed
2016-12-03 12:12:22 89.188.9.41: PHP built
...

And as for updating I made a typo (tired, sorry): it is "./build update" followed by "build php". There are no conversions from a previous system. As I said I started this server (like my other DA servers) from scratch. I update PHP every time there are important changes and nginx only occasionally. There is just one extension to DA: Configserver Firewall but that has nothing to do with what I am trying to achieve here.

So this is NOT about "conversion from system to another". It is a clean, independent installation for a group of customers that share the same requirements. I am running now two other servers with Directadmin and have used DA and Custombuild since 2008 or 2009, probably (though not sure whether CB was available then).

So "you are doing something wrong" cannot be the case because I have forced myself to do everything the DA way. And this because I need to be sure a less tech-savvy person may also perform the same tasks without going to the shell.

What I really was after, however, was an answer to this simple, original question (I do NOT want to build PHP every time so the discussion went to the side ways):

Is there a recommended way to get rid of the cumbersome PHP builds and use a stock Remi (or some other) build?

I know I can figure it out by inspecting the configuration files but it would be nice to see if anybody has done it yet. DA is very nice for non-techy people for creating email accounts and doing small maintenance but pretty horrible for server software updates.

regards
Markku
 
Now another show stopper:

A customer said she could not upload images to her site. The problem was this time that the upload_tmp_dir was /var/www/tmp and it was NOT included in the open_basedir list of directories. The next thing to do is have a look at the data/templates/php-fpm.conf. The OPEN_BASEDIR_PATH line is beyond belief (including PHP54 and PHP55 paths) BUT does not include /var/www/tmp.

So my next question is WHAT ON EARTH IS GOING ON with DA/Custombuild???? Who is responsible for this mess? Does anybody test/review the setups?

This time I hand edited every open_basedir for a dozen customers as a quick fix and corrected the template setting for the future, if any. Where do all this messed-up settings emerge from?

Markku
 
Regarding your problem after upgrading PHP and sessions, please see this thread: http://forum.directadmin.com/showthread.php?t=54902

Thanks, that explains some of the problems (like the session stuff) but not all of them because the user/group problem is separate from PHP and the same goes for open_basedir which is created by DA. A user cannot write to a directory where he has no permissions or which is outside open_basedir.
 
Hello Markku,

Yes, there was an incident with /var/www/tmp and settings which were meant to work only for roundcube, phpmyadmin, squirremail became global for all users. The session path was changed by John a while ago only for web-applications for security reasons, and no users should be allowed to either read or to write there. More information can be found here: http://forum.directadmin.com/showthread.php?t=50545

As for moving to using RPM packages. That's possible I'd rather say, but I did not use it or try it with Directadmin. Actually it does not really matter how you install PHP: either from sources with custombuild or from RPM packages, you should only care about paths.

If you still want to use RPMs, here is what I'd suggest that you check:

1. make sure your version in custombuild is the same as installed from rpm, otherwise you might have issues (as NGINX config trying to connect an user to a wrong FPM socket).
2. you will need probably to place php-binaries in a place where directadmin expects them to find, otherwise you will most likely need to customize directadmin templates.
3. update /etc/yum.conf to stop excluding *php* packages.
4. you will need to take care of monitor in Directadmin. Names should match, and init/systemctl scripts should match with their names also.
5. make sure that PHP installed from RPM reads configs from Directadmin, otherwise you might have issues as no FPM-pool for a newly created users.

Here is what comes to my mind, and the list might be not final.

Anyway if you run multiple servers with the same OS version you might consider using your own RPM repository. In this case you could use directadmin native paths for binaries and configs.
 
Ok, Alex

I thought there could be an initial option to choose either "repo" or "source" in CustomBuild but that is another story, of course and needs not be taken any further. I understand that is a major thing and the script is pretty massive already.

I have a working set of small applications and user interfaces that can do roughly 80% of what DA does for me so I will probably switch to it - on a fresh server. I will definitely not start making tests on a production server but continue running the sites with a bit lower security instead.

DA's problems with open_basedir, upload_tmp_dir and session handling are now in such a state that I really do not know how to start repairing them the proper way. The whole idea has been broken in DA now, anyway, and somebody need to analyze it properly. Things to do are (at least):

#1) Make sure every can save sessions to the file system
#2) Make sure every directory needed/set up by PHP is accessible to a user (open_basedir)
#3) Make sure the permissions are correct for every single normal user case (like file uploads or writing to a temporary file)

We did not have problems like the ones I have stumbled onto years back. I do not remember making changes in permissions or configuration templates before to make things work.

Markku
 
Markku,

Yes, there is no easy way to migrate to RPMs mode.

At those old days we had only 2 options in Directadmin:

- apache+mod_php (and all PHP scripts executed with user apache permissions)
- apache+suphp

Now we have:

- mod_php + mod_ruid2
- PHP-FPM
- FASTCGI
- suPHP

CentOS 7 and Debian 8 with private tmp.

Things changed and we need new solutions.

As a quick and temporary solution you can disable open_basedir restrictions for all users, and then change everything to defaults, user-by-user enabling open_basedir back.

The command:

Code:
/usr/local/directadmin/scripts/set_permissions.sh all


should reset permissions https://help.directadmin.com/item.php?id=173


 
Last edited:
Back
Top