CustomBuild corrupted a fresh system

C

codes9

Verified User
Joined
Sep 5, 2019
Messages
74
I've recently installed a new Directadmin server. The setup is mostly stock with php7.4 fpm

Custombuild has gotten stuck on an issue around ProFtp

Code: 
           unified_ftp_password_file is not set to 1.  You must convert before you can use pureftpd Please read this guide: https://www.directadmin.com/features.php?id=1134 Simulation:     cd /usr/local/directadmin     echo 'action=convert&value=unifiedftp&simulate=yes' >> data/task.queue     ./dataskq d1 Conversion:     cd /usr/local/directadmin     echo 'unified_ftp_password_file=1' >> conf/directadmin.conf     echo 'action=convert&value=unifiedftp' >> data/task.queue     ./dataskq d1
The custombuild config file ended up having 10 or more duplicates of every setting.

Apache config was left in a broken state. Remove one error and the next shows up.

Code: 
[root@24 ssh]# apachectl configtest
AH00526: Syntax error on line 32 of /usr/local/directadmin/data/users/admin/httpd.conf:
Invalid command 'php_admin_value', perhaps misspelled or defined by a module not included in the server configuration

DNS has gone down, Apache won't restart, Custombuild won't build.

How do I fix this?

@smtalk have you seen anything like this occuring on a fresh install?
 
codes9 said:
I've recently installed a new Directadmin server. The setup is mostly stock with php7.4 fpm

Custombuild has gotten stuck on an issue around ProFtp

Code: 
           unified_ftp_password_file is not set to 1.  You must convert before you can use pureftpd Please read this guide: https://www.directadmin.com/features.php?id=1134 Simulation:     cd /usr/local/directadmin     echo 'action=convert&value=unifiedftp&simulate=yes' >> data/task.queue     ./dataskq d1 Conversion:     cd /usr/local/directadmin     echo 'unified_ftp_password_file=1' >> conf/directadmin.conf     echo 'action=convert&value=unifiedftp' >> data/task.queue     ./dataskq d1
The custombuild config file ended up having 10 or more duplicates of every setting.

Apache config was left in a broken state. Remove one error and the next shows up.

Code: 
[root@24 ssh]# apachectl configtest
AH00526: Syntax error on line 32 of /usr/local/directadmin/data/users/admin/httpd.conf:
Invalid command 'php_admin_value', perhaps misspelled or defined by a module not included in the server configuration

DNS has gone down, Apache won't restart, Custombuild won't build.

How do I fix this?

@smtalk have you seen anything like this occuring on a fresh install?
Click to expand...
No, it hasn’t been reported. Did you use any custom settings there?
 
smtalk said:
No, it hasn’t been reported. Did you use any custom settings there?
Click to expand...
No actually just spun up a standard DirectAdmin install.

I added proFtp which is what seems to have done it. The config file had all the initial settings and then started at the php version 1,2,3,4 again repeating all the variables over and over 7-8x.

Suspect each try to disable proFtp resulted in duplicates. The outcome after this was a broken system. I've given up and reinstalled on a different Ubuntu 20.04 as I've got time pressure to make the migration.

New installs had none of these issues. So I suspect I hit some sort of bug.
 
smtalk said:
No, it hasn’t been reported. Did you use any custom settings there?
Click to expand...
He shouldn't doublepost, but he did already report it here:

HTTPD Down, Custombuild broken

On a fresh Directadmin install I've brought the Webserver up. After making some changes on Custombuild everything worked but broke the next day. It appears the options.conf and other files got corrupted. In options.conf there was major duplication of settings. I've cleaned this up but...
forum.directadmin.com forum.directadmin.com
 
Richard G said:
He shouldn't doublepost, but he did already report it here:

HTTPD Down, Custombuild broken

On a fresh Directadmin install I've brought the Webserver up. After making some changes on Custombuild everything worked but broke the next day. It appears the options.conf and other files got corrupted. In options.conf there was major duplication of settings. I've cleaned this up but...
forum.directadmin.com forum.directadmin.com
Click to expand...
Sorry @Richard G I've lost track where I asked for help in the past week. Your response in the above thread was the most useful response.

After mostly deflection from DirectAdmin and Datacenters on this issue I had to pull the plug and do all of it again since our old server is degrading fast.

I've dealt with total disk corruption on the other DirectAdmin server I use as our primary name server and after failed data-center restores to known good state days I had to rebuild and re-migrate. This is days after starting to migrate users over. I had just reloaded and re-migrated user accounts this server when the above issues started. Given the situation with current servers my tolerance for out of the box failures has been quite low and pressure on.

To add insult to injury most DirectAdmin backups I'm bringing in from the old servers fail to restore or partially restore with wrong email passwords, missing database imports, missing dns zones, and no errors in DirectAdmin. The back and forth also with server re-deployments also means I'm bringing in email by hand (so all manual really). Luckily we keep a lot of versions of backups. But even then most of the migration needs to be completed by hand and I've had to pull databases by hand as well. It's a first time I've seen this on DirectAdmin which has become a very reliable system for us. I'm going to need to find a way to test backup integrity after the migration is over.
 
codes9 said:
I'm bringing in from the old servers fail to restore or partially restore with wrong email passwords, missing database imports, missing dns zones, and no errors in DirectAdmin
Click to expand...
pity to hear but I am not sure if this the fault of DA, migrating for years with backup created by Da and never had problems.
Even recent , 5 days ago we have migrated an old server to an new Almalinux server with use of only DA backups.

The way we follow is that we always make backup as "Reseller" and not Admin (never liked trough), maybe this helps
 
codes9 said:
Given the situation with current servers my tolerance for out of the box failures has been quite low and pressure on.
Click to expand...
OMG, when reading this, I can really understand you're under pressure and tolerance is lowering to a very low point. Been there too, luckily that was a lot of years ago and before we started using raid 1 and munin for system monitoring.
Maybe that's a tip for you. You can use munin quite easily, it's not too heavy and you get fair warning on time when disk are starting to get issues if all goes well.

If you had disk problems, this might already have been cause for backups to go wrong. One never knows. Hope you get it straigtened out soon so you can come to rest a bit and stresspoint will lower again.

Active8 said:
we always make backup as "Reseller" and not Admin (never liked trough), maybe this helps
Click to expand...
So what is the difference in this? As far as I've seen from... who was that again.. another user here discovered that, sorry, forgot the name, but all backups are the same, just the naming is different but the way things are backepd up are the same.
 
Richard G said:
but all backups are the same, just the naming is different but the way things are backepd up are the same.
Click to expand...
Maybe, but as said never liked admin backups form day one we used first DA server till now doing like this works flawless
But hey this is an personal thing :)
 
Ah oke a personal choice, that's good. I thought it maybe was an interesting technical reason with benefits, so it made me curious. Thanks!
 
You must log in or register to reply here.
Back
Top