New build system (BETA)

jlasman said:
Martynas, can the link be added automatically somewhere when the conversion to CustomBuild is done? (on 64-bit operating systems)?
Click to expand...

It's added to the CustomBuild 1.2 (which is in development). CustomBuild 1.1 is feature frozen, so, you should ask John to include it (everything is done (to 1.1.x) from my part). Only 1 new feature is coming to 1.1 (it's done, just needs to be included), but it will be a separate file (options). It will ask you what do you want to have (update/install) etc.
 
Don't know, I've only once run custombuild, and it wasn't for the first time. I'm thinking that whoever runs it for the first time should have some notice that the files are being changed but originals are being saved.

Jeff
 
jlasman said:
Martynas, I understand your reply, and I understand Chrysalis's original post.

What I don't know (hopefully you can tell me) is whether or not there's a warning when the conversion is done that you may have to import any custom changes from your old httpd.conf file to the new one, and is the old one saved?

As long as both above are true, then I don't see a problem, though if a lot of folk are going to convert then perhaps one of us (not me ;) ) can create a little script using some intelligent diffing and patching to automate it.

Jeff
Click to expand...

yep this is what I think can be done, a diff should see if the config files need changing and if they do a patch should work.

Smtalk I wasnt trying to be rude I understand you have done a great deal of work into custombuild and it is a good script there was no bug report from me as at the time I didnt have time to document what went wrong as I was restoring a server following hardware failure and the downtime had to be minimised, I do plan to send you some more feedback however.
 
Custombuild checks if /etc/httpd/conf/extra directory exists, and if it is - it doesn't touch /etc/httpd/conf/httpd.conf at all.
 
BigWil said:
I understand the need to upgrade to bigger and better things but issues like Apache 2 not having mod_frontpage and suPHP not allowing .htaccess files sort of stands in our way.
Click to expand...

You don't have to use suphp with apache 2/2.2 just switch to cli in options.conf. In fact, we don't use suphp, until issues with suphp are sorted out.

(Martynas, how's it going with htscanner/vhosts? we can offer assistance/test environment if necessary)

In short I need Apache 2, PHP4, suPHP with Mod_Frontpage and the abilility to expand to PHP5 in the future once the security for the product is stable.
Click to expand...

That's a truly obsolete environment. We have lost some prospective customers last year bc of our inability to support PHP5 back then, and to lesser extent Apache 2.

More and more of our customers need and ask for things like new PHP extensions, PDO, various PEAR soft, little-known things like support for FreeTDS in PHP, freetype, new e-commerce solutions use all kinds of features in PHP5, etc.

The reasons behind this are simple to understand and undeniable: machine time is cheap nowadays, human labor time is expensive. If anything can boost programmer's productivity and time-to-market for a given solution, that's worth dumping tested environment like apache 1.3/php4 and switching to not yet as well tested php5. Which, to be frank, isn't all that new, is it?

Mod_Frontpage needs to stick around no matter what. There are still millions of customers that have Frontpage and will continue to use Frontpage no matter what Microsoft says.
Click to expand...

Well, I haven't had a single customer that uses FP. Basically nobody seems to use it around here. Perhaps in Europe things are tad different.
 
Ok. I thought that suPHP refused to process .htaccess files. That is the impression I got but maybe I misread. So then there are just certain things that it refuses to process within the .htaccess files?

Big Wil
Click to expand...

It barfs on php_value / php_flag directives.
 
Marcin said:
More and more of our customers need and ask for things like new PHP extensions, PDO, various PEAR soft, little-known things like support for FreeTDS in PHP, freetype, new e-commerce solutions use all kinds of features in PHP5, etc.
Click to expand...

Why can't one give customers new php extensions, pear and things like freetype with PHP4. We have been supporting all of this in PHP4 for years now.

For us E-Commerce and PHP5 hasn't even been considered as a serious possibility yet. PHP5 has had so many security vulnerabilities that we wouldn't even think of it at this point. http://www.php.net/ChangeLog-5.php I say wait until the platform stablizes a little before putting your hosting companies liability premium at risk. ;-) Remember that the millions of dollars worth of credit card transactions that cross or are stored on your servers are only as safe as the security on your machines allow.

Marcin said:
The reasons behind this are simple to understand and undeniable: machine time is cheap nowadays, human labor time is expensive. If anything can boost programmer's productivity and time-to-market for a given solution, that's worth dumping tested environment like apache 1.3/php4 and switching to not yet as well tested php5. Which, to be frank, isn't all that new, is it?
Click to expand...

Saving a few bucks in personnel time at the cost of putting a customers data at risk just isn't responsible business nor smart as it will come back to the host that allowed it to happen. Until the security audits start coming back clean... yes it is brand new.

Marcin said:
Well, I haven't had a single customer that uses FP. Basically nobody seems to use it around here. Perhaps in Europe things are tad different.
Click to expand...

About 1 of 50 still use it here. Probably for being a MS Certified FP host for so many years. Hard to teach old dogs new tricks sometimes. I hate the product myself but as long as the site is static and there is no real security risk I let them use the WYSIWYG editor of their choice. I am a notepad guru myself. As for European, well if that is a way for me to land those fine European chicks then yah European it is. Otherwise, nope just a good old fashion USA born and raised web hoster here.

Big Wil
 
Marcin said:
You don't have to use suphp with apache 2/2.2 just switch to cli in options.conf. In fact, we don't use suphp, until issues with suphp are sorted out.

(Martynas, how's it going with htscanner/vhosts? we can offer assistance/test environment if necessary)
Click to expand...

When we will have beta (or release candidate) of htscanner - I'll be able to include it. I don't want to use alpha versions into the stable CustomBuild script.
 
smtalk said:
When we will have beta (or release candidate) of htscanner - I'll be able to include it. I don't want to use alpha versions into the stable CustomBuild script.
Click to expand...

I rather meant this problem we encountered - whether htscanner works in your setup in vhost context.
 
Marcin said:
You don't have to use suphp with apache 2/2.2 just switch to cli in options.conf. In fact, we don't use suphp, until issues with suphp are sorted out.
Click to expand...
This loses me, probably because I'm not a PHP programmer.

What method does CustomApache use for getting PHP to work with apache1? with apache2?

Can the same method be used in CustomBuild? Is it the default?

Please pardon my ignorance and help me understand.

Thanks.

Jeff
 
Yes, it's default (CLI installation). Marcin wants to see php_value support for CGI installation of PHP (using suPHP), but that requires htscanner (which is in alpha).
 
I have installed Directadmin with the custombuild but apache wont start.
I have tried to rebuild apache, and also reinstalled directadmin but the problem is still there.
(OS: centos 4.4 32bit)

the apache error log said:
PHP: 
[Fri Oct 12 16:16:11 2007] [error] mod_ssl: Init: Unable to read server certificate from file /etc/httpd/conf/ssl.crt/server.crt (OpenSSL library error follows)
[Fri Oct 12 16:16:11 2007] [error] OpenSSL: error:0D06B08E:asn1 encoding routines:ASN1_d2i_bio:not enough data

I will used now:

default_php=5
php5_cli=no
php5_cgi=yes
php4_cli=yes
php4_cgi=no
php_ini=yes
#Possible values - recommended or dist
php_ini_type=recommended
zend=no

#Possible values - 5.0 or 5.1 (4.1 is possible too, but it's EOL)
mysql=4.1
mysql_inst=yes

#Possible values - 1.3, 2.0 or 2.2
apache_ver=1.3


EDIT: now i have upgrade to apache 2.0, no succes.
Downgrade to 1.3, apache runs but php4 can not be load.

Edit:
pfff, reinstall van build all give now also a 404 error voor de mysql files:

--17:13:30-- http://files.directadmin.com/services/all/mysql/MySQL-server-5.1.20-0.i386.rpm
=> `MySQL-server-5.1.20-0.i386.rpm'
Resolving files.directadmin.com... 72.35.85.222
Connecting to files.directadmin.com|72.35.85.222|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
17:13:30 ERROR 404: Not Found.
 
Last edited:
I just installed my new DirectAdmin system, but why the hell do we still get the choice for PHP4 and MySQL 4.1?

Those are both EOL, PHP4 gets supported for a few months and then it is gone.

Now i get suPHP on my system, wich i have to remove in order to install PHP5 as a module.

Backwards compatability is fine, but i think this is a little TO much. Please, let the world stop with all the 4.x software and focus on the new software. Push your customers towards PHP5 and MySQL5.

We have been running PHP5 and MySQL5 only for more then a year now with 20.000 shared hosting accounts. It runs fine, no troubles at all!
 
Wido, thank you for your opinion. In CustomBuild 1.2 we will only have PHP5 and PHP6. :)
 
smtalk said:
Wido, thank you for your opinion. In CustomBuild 1.2 we will only have PHP5 and PHP6. :)
Click to expand...
Great! :)

No offence though, i just hate it when people keep running outdated software when there is so much better out there.

A simple question in custombuild 2.1

Do you want:
- Apache 2.2
- PHP5 (DSO)
- MySQL5

If so, so, type "Yes", if you want advanced options, type "No":
Click to expand...

The performance of PHP is at its best when running in DSO.

If people want to keep their backwards compatability, they should choose for it. You should encourage admins to install their systems with the new software.
 
php4 is still used because of demand its one thing saying everyone should just dump it but I expect for many providers its not a simple choice to make. The best workaround is php5 and 4 together on the same server which custombuild offers.

If you dont want php4 then choose php5 whats wrong with that.
 
When you build with custombuild and install both php4 and php5, how do you specify which version of php you're calling?

And how is PHP run?

Jeff
 
I'm still confused, probably because I'm not a php programmer.

I think you've answered the first question :) .

Now for the second ...

We've always installed php through customapache. I believe this isntalls PHP to run as a module in apache. How does custombuild run the two versions?

And how does this affect any currently running script on the server? New ones?

(For better or worse ;) )

Thanks!

Jeff
 
You must log in or register to reply here.
Back
Top