The installation process on FreeBSD is completely messed up. You need to make sure CB doesn't run and uninstall all the packages DA installs before installing libs via ports and proceeding with CB (which has improved in the way it looks for dependencies).Even if you still use GCC and you do not port DirectAdmin to 10.x yet, the issue with pkgng replacing old pkg_ system will be on 9.x series too:
I get this warning on a fresh installed server with FreeBSD 9.2:
make install clean
/!\ WARNING /!\
pkg_install EOL is scheduled for 2014-09-01. Please consider migrating to pkgng
If you do not want to see this message again set NO_WARNING_PKG_INSTALL_EOL=yes in your make.conf
Sorry for the late response! I'll make sure to enable forum notifications from now on.Portsbuild sound interesting
How do you inject all the extra required patches into ports? Via make.conf?
portmaster -d lang/php5 www/apache24 mail/exim databases/mariadb55-server [...]
Yup. To combat this problem, I will have to rewrite parts of DirectAdmin's setup.sh and offer an alternative script for us BSD'ers. I have yet to dive into setup.sh, but I am sure it can be done.The installation process on FreeBSD is completely messed up. You need to make sure CB doesn't run and uninstall all the packages DA installs before installing libs via ports and proceeding with CB (which has improved in the way it looks for dependencies).
I would think so. The default install for 10 has pkgng out of the box, and there is no going back. 8.3-9.x have options for a DA install. I'd guess that if your conditionals are based on whether or not it is pkgng, rather than OS version, your code would fix 10.x, and those that migrate to pkgng from 8.3-9.x. The binaries are not the problem.A question for all: is it best to target PB for (new) 10.x installs first, with a focus on 9.x deployments later on?
exim_enable="YES" clamav_clamd_enable="YES" clamav_freshclam_enable="YES" spamd_enable="YES" spamd_flags="-c -m 15"
Thank you for your kind words! Do you know about a CB feature which allows you to disable management of specific component? (so that it wouldn't be listed in "./build versions" and places like that). Please check #29 of http://forum.directadmin.com/showthread.php?t=44743. It might be worth to disable specific components you manage in CB 2.0, so that they'd be controlled by your script. That way you could take control of SA+ClamAV only, for example.That's when I realized @smtalk was in the middle of adding pkgng support to a few applications, and how much blood and sweat he puts into something thousands of DirectAdmin sysadmins use everyday.
Thank you for making our lives easier!Thank you for your kind words! Do you know about a CB feature which allows you to disable management of specific component? (so that it wouldn't be listed in "./build versions" and places like that). Please check #29 of http://forum.directadmin.com/showthread.php?t=44743. It might be worth to disable specific components you manage in CB 2.0, so that they'd be controlled by your script. That way you could take control of SA+ClamAV only, for example.
Hi John, thanks for the reply!Hmm.. I don't recall seeing the E-Mail, but regardless we are interested in getting it out, in some form or another.
If the scripts are full rewrites, then by all means, you're welcome to release them.
But.. if they're only surgical changes, then perhaps a set of patches may work?
Maybe trying email again and I'll keep my eye out for in in our mail logs.
I'll look for the domain value set in the email for your forum username.
We can get a better idea on which direction to go once I see them
Awesome work mmx! Do you happen to know if DirectAdmin is going to support your packages?Hi John, thanks for the reply!
I haven't made up my mind yet whether I want to release patches, full rewrites, a new script, or a mix of all three. I was hoping to get an okay to release the original (non-modified) scripts from update.tar.gz to simplify deployment. I want to make installation simple: "just download and overwrite" as opposed to "run this patch and replace these files" although most functions can be automated via scripting.
A lot of the files in scripts/ can be shrunk down by removing the Linux-specific code, however I am uncertain which way to proceed, as every scenario has both pros & cons.
I have a few installation scenarios and deployments in mind:
- Patch and Patch: patch setup.sh and patch files in scripts/ via one "patch.sh" file fetched separately. This allows both DirectAdmin+CB and PortsBuild code-bases to be similar and allows easier parallel development. Only the code for "patch.sh" will be made public, which is essential a file full of Perl/awk/grep/sed replacement routines that must be run in scripts/ after a modified setup.sh is executed. Downside for me is a larger code base to go through every time a major release is made.
- Patch and Re-Release: patch setup.sh, patch files in scripts/ and release a "revised" update.tar.gz. Like #1, it just makes distribution simpler for users. All of the contents of update.tar.gz will be made public (this is where I am asking for approval) minus the compiled binaries.
- Patch, Full Replace and Re-Release: patch setup.sh, patch files in scripts/, replace or remove unneeded scripts, and release a "revised" update.tar.gz (like #2). This branches off into its own code-base (with Linux-specific code removed) yet follows the same style of scripting and function-calling of the original update.tar.gz.
- Patch and New Release: patch setup.sh, call a new script "portsbuild.sh" to auto-install all libs, deps and services from ports. This is branching off from install.sh and CustomBuild entirely. It will replace update.tar.gz completely, minus the compiled binaries. Existing code from the tarball will be used, hence authorization & permission is still required to distribute the original files or re-use functions written by DirectAdmin. This is where I ultimately see myself going.
I'll resend the email once more. I can show you some examples once I clean up the code. Thanks!