Search results

That won't work unless there is a team dedicated to building safe rules which are compatible with most apps a typical user would want to install.

I second that. You'll have to write lots of exception rules, will have slower pings and might have lock ups when attacked. Installing it is the easy part.

Yep and a new set of skills would be required to properly configure those VLCs. I'm just mentioning it because even though NGINX is able to do static caching in memory, people still tend to put Varnish in front of it.

Why not use Varnish to cache static files from RAM? I guess since CB already has all the code to install NGINX that it's quicker to set up, but Varnish can benefit both Apache and NGINX.

Ah, of course... I had forgotten that the configuration was, in fact, a script. That's a clever way to do it :). I still think a for-each-patch loop in a function could make things easier, but I reckon that custom patches is probably something that less than 1% of the CB users are implementing...

Yes, although it could simply be that something went wrong during the upgrade, but you couldn't see it because CB whizzed through the installation process.

Is there some documentation somewhere? I usually just add my patches to the code, but was hoping for an easier way.

mod_proxy_handler should simplify things :) and good news about RC7. CB 2.0 definitely needs to be upgraded or you won't be able to upgrade Apache, but maybe a new version hit the servers.

This is Dovecot's fault. Over time, you accumulate different versions of the same libraries in /usr/lib/dovecot and Dovecot tries to load them all.

I've just checked doApache2() and all I see are hard-coded patches echo "Extracting ${FILE}..."; tar xzf ${FILE} --no-same-owner if [ "${APACHE_OPT}" = "2.4" ]; then FILE2=${CWD}/apr-${APR_VER}.tar.gz checkFile ${FILE2}; echo "Extracting ${FILE2}..."; tar xzf ${FILE2}...

It's great to be able to customise configuration files with the custom folder, but the same concept could be applied to patches. CB should use any patches it finds in our custom folders It could look like this, which is the way DA does thing: patches patches/apache2...

Apache 2.4.9 will be released soon and some patches in CB won't be needed any more. Changelog: http://httpd.apache.org/dev/dist/CHANGES_2.4.9 Some of the changes which may affects the patches some of us use: mod_proxy_fcgi: Use apr_socket_timeout_get instead of hard-coded 30 seconds timeout...

My suggestions: Don't touch directadmin.ini, just create a mycustom.ini file and add your extensions there. You never know when custombuild is going to overwrite that directadmin.ini file. No need to add the full path, just type extension=mailparse.so

In quite a few places, when you click on the "back" link at the bottom of the enhanced skin, you end up with a DA 404. Using the back button in the browser is never the solution as the page doesn't get refreshed. The URL is domain.tld:2222/none Some examples of location where this happens...

Works as expected and drastically reduces the number of domains. Thanks for that.

Where do we fill these variables? Simply create domain.tld.cust_php and add our content to |?CUSTOM2=|?

Sounds good :) Is it already available in 1.45 beta?

I agree, this feature should be extended to support a custom list of extractors. format|extract command|compress command tgz|tar xzvf| tar czvf bz2|tar xjvf| tar cjvf rar|unrar -e| NA

Specific indeed, but the reason the check is in place is purely so that customers don't screw it up, so it should be possible to lift that limitation for people who know what they're doing. An extra variable in CMD_API_DOMAIN perhaps. And yes, the reason to separate them is so that they can't...

Unless I'm mistaken adding a custom config to a domain alias won't do anything, since all DA does is add the domain to the ServerAlias directive. Am I missing other use cases?