FreeBSD 11.0 64-bit ALPHA release

DirectAdmin Support

Administrator
Staff member
Joined
Feb 27, 2003
Messages
9,158
Hello,

FreeBSD 11.0 64-bit has been released for ALPHA testing.

Please report bugs to the FreeBSD 11.x 64-bit forum, and not via E-Mail/Ticket

Note that we don't yet recommend it for production use, as it has very time being tested, so there is an increased chance of finding a bug.
If you wish to try it out now, the name is "F11 64-bit ALPHA" on the licensing page.

Note that the major changes with the DA setup and FreeBSD 11 is that we don't use pre-compiled binaries for exim or proftpd.
This means that CustomBuild will compile exim by default, so be extra sure you've fully installed all pre-install packages or the whole DA install might fail if exim doesn't compile correctly.

John
 
Hello,

FreeBSD 11.0 64-bit has been released for ALPHA testing.

Please report bugs to the FreeBSD 11.x 64-bit forum, and not via E-Mail/Ticket

Note that we don't yet recommend it for production use, as it has very time being tested, so there is an increased chance of finding a bug.
If you wish to try it out now, the name is "F11 64-bit ALPHA" on the licensing page.

Note that the major changes with the DA setup and FreeBSD 11 is that we don't use pre-compiled binaries for exim or proftpd.
This means that CustomBuild will compile exim by default, so be extra sure you've fully installed all pre-install packages or the whole DA install might fail if exim doesn't compile correctly.

John

This is great news! :cool:
 
So far it works with just few bugs.

I did install all preinstall packages according the instructions on the install page. During the installation I chose PHP 7.1 SuPHP as primary and PHP 5.3 SuPHP as secondary. The 5.3 failed to compile and the setup stopped.

Then I did reinstall directadmin with "./directadmin i" and went to Custombuild to recompile the missing services one by one. PHP 5.3 is a no-go. I switched it to 5.4 and it compiled fine.

The other service that did not compile was the Spamassassin - it needed some cpan modules installed first. After installing the modules, everything was fine.

There's an error during ./build update - it tries to download ".tar.gz" file with no name and it fails, but that's not a big problem - it works regardless that.

Downloading .tar.gz...
fetch: http://files18.directadmin.com/services/custombuild/.tar.gz: Not Found
Downloaded file /usr/local/directadmin/custombuild/.tar.gz does not exist or is empty after download
cwd is: /usr/local/directadmin/custombuild
Fileserver might be down, using the backup file server..
fetch: http://69.162.69.58/services/custombuild/.tar.gz: Not Found

Bruteforce monitor, exim.conf 4.5 - works fine.

When making ./build versions I get the following errors:

...
Latest version of autoconf: 2.68
Installed version of autoconf: 2.68

Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/\${ <-- HERE ([^ \t=:+{}]+)}/ at /usr/local/bin/automake line 3936.
Latest version of automake: 1.15
Installed version of automake: 1.15
...

and

...
Latest version of MariaDB: 5.5.54
Installed version of MariaDB: 5.5.54

Failed loading /usr/local/lib/ioncube/ioncube_loader_fre_5.4.so: Cannot open "/usr/local/lib/ioncube/ioncube_loader_fre_5.4.so"
Latest version of PHP 5.4: 5.4.45
Installed version of PHP 5.4: 5.4.45
...

I know there's no ioncube for PHP 7.1 but that was for 5.4. I did download the .so file manually and it worked fine.
 
Last edited:
Another issue is related to MariaDB - I can only compile 5.5, but not 10.0 or 10.1. Here's the error:

config.status: creating config.h
config.status: executing depfiles commands
config.status: executing libtool commands
config.status: executing po-directories commands
config.status: creating po/POTFILES
config.status: creating po/Makefile
A failure has been detected in another branch of the parallel make

make[2]: stopped in /usr/local/directadmin/custombuild/mariadb-10.1.21
--- storage/tokudb/PerconaFT/CMakeFiles/build_lzma.dir/all ---
*** [storage/tokudb/PerconaFT/CMakeFiles/build_lzma.dir/all] Error code 2

make[1]: stopped in /usr/local/directadmin/custombuild/mariadb-10.1.21
9 errors

make[1]: stopped in /usr/local/directadmin/custombuild/mariadb-10.1.21
*** [all] Error code 2

make: stopped in /usr/local/directadmin/custombuild/mariadb-10.1.21
1 error

make: stopped in /usr/local/directadmin/custombuild/mariadb-10.1.21

*** The make has failed, would you like to try to make again? (y,n):
 
I tried doing manually "make" to see if MariaDB 10.1 will compile and I got the following error:

[ 82%] Building CXX object storage/test_sql_discovery/CMakeFiles/test_sql_discovery.dir/test_sql_discovery.cc.o
[ 82%] Linking CXX shared module ha_test_sql_discovery.so
[ 82%] Built target test_sql_discovery
[ 83%] Building CXX object storage/tokudb/PerconaFT/portability/CMakeFiles/tokuportability_static_conv.dir/toku_crash.cc.o
/usr/local/directadmin/custombuild/mariadb-10.1.21/storage/tokudb/PerconaFT/portability/toku_crash.cc: In function 'void run_gdb(pid_t, const char*)':
/usr/local/directadmin/custombuild/mariadb-10.1.21/storage/tokudb/PerconaFT/portability/toku_crash.cc:73:16: error: missing sentinel in function call [-Werror=format=]
NULL);
^
cc1plus: all warnings being treated as errors
*** Error code 1

Stop.
make[2]: stopped in /usr/local/directadmin/custombuild/mariadb-10.1.21
*** Error code 1

Stop.
make[1]: stopped in /usr/local/directadmin/custombuild/mariadb-10.1.21
*** Error code 1

Stop.
make: stopped in /usr/local/directadmin/custombuild/mariadb-10.1.21
root@srv2:/usr/local/directadmin/custombuild/mariadb-10.1.21 #

I did make:

cmake -DPLUGIN_TOKUDB=NO
cmake -DPLUGIN_OQGRAPH=NO

then "make" again and it compiled correctly.
 
Last edited:
After updating all ports with "portmaster -a" the regex error during "build versions" is gone.

Now just a tiny minor issue - I guess few ports from DA are older then what the portstree provide:

Latest version of libpng: 1.6.28
Installed version of libpng: 1.6.28+apng

Libpng 1.6.28+apng to 1.6.28 update is available.

Latest version of nghttp2: 1.18.0
Installed version of nghttp2: 1.19.0

Nghttp2 1.19.0 to 1.18.0 update is available.
 
dovecot FreeBSD 11

I get the following on compiling dovecot (custombuild)

./.libs/libcharset.a(charset-iconv.o): In function `charset_to_utf8_try':
/usr/local/directadmin/custombuild/dovecot-2.2.28/src/lib-charset/charset-iconv.c:78: undefined reference to `libiconv'
./.libs/libcharset.a(charset-iconv.o): In function `charset_to_utf8_begin':
/usr/local/directadmin/custombuild/dovecot-2.2.28/src/lib-charset/charset-iconv.c:29: undefined reference to `libiconv_open'
./.libs/libcharset.a(charset-iconv.o): In function `charset_to_utf8_end':
/usr/local/directadmin/custombuild/dovecot-2.2.28/src/lib-charset/charset-iconv.c:48: undefined reference to `libiconv_close'
./.libs/libcharset.a(charset-iconv.o): In function `charset_to_utf8_reset':
/usr/local/directadmin/custombuild/dovecot-2.2.28/src/lib-charset/charset-iconv.c:55: undefined reference to `libiconv'
collect2: error: ld returned 1 exit status
gmake[3]: *** [Makefile:488: test-charset] Error 1
gmake[3]: Leaving directory '/usr/local/directadmin/custombuild/dovecot-2.2.28/src/lib-charset'
gmake[2]: *** [Makefile:495: all-recursive] Error 1
gmake[2]: Leaving directory '/usr/local/directadmin/custombuild/dovecot-2.2.28/src'
gmake[1]: *** [Makefile:618: all-recursive] Error 1
gmake[1]: Leaving directory '/usr/local/directadmin/custombuild/dovecot-2.2.28'
gmake: *** [Makefile:462: all] Error 2
 
After updating all ports with "portmaster -a" the regex error during "build versions" is gone. Now just a tiny minor issue - I guess few ports from DA are older then what the portstree provide:
It has been more than a year since you posted last. I use the normal FAMP stack w/Exim, ClamAV, Dovecot, Squirrel Mail, etc. I have a few questions about the install:
1. What are the software install requirements prior to setting up DA on FreeBSD 11.1?
2. What problems need to be worked around manually where the installation bombs?
3. I need php 5.x + CLI + MOD_PHP + IONCube. How far back can I go in the PHP 5 branch? PHP 7.x would be nice as an option, but I'd likely to run into issues with some sites not using the newer MySQLi.
4. Does DA's current branch work with FreeBSD 11.1 or does it use an old version like before? Does the mail plugin work with it?
5. Can you do standard DA updates to update the software without it breaking things?

Thanks!
 
1. Usually what is listed on the DA website (I updated bind to 912 instead of 99):

# pkg install gcc gmake perl5 wget bison flex cyrus-sasl cmake python autoconf libtool libarchive iconv bind912 mailx webalizer

2. MariaDB won't compile. When you install a fresh server, you can skip installing it. Then you will add it in options, download the tar.gz and install manually the following way:

# cd /usr/local/directadmin/custombuild
# rm -rf mariadb-10.2.15
# tar -zxvf mariadb-10.2.15.tar.gz
# cd mariadb-10.2.15
# cmake -DPLUGIN_TOKUDB=NO -DPLUGIN_OQGRAPH=NO -DPLUGIN_MROONGA=NO -DPLUGIN_ROCKSDB=NO -DWITHOUT_MROONGA_STORAGE_ENGINE=YES -DWITHOUT_TOKUDB_STORAGE_ENGINE=YES -DWITHOUT_ROCKSDB_STORAGE_ENGINE=YES
# make install
# /usr/local/etc/rc.d/mysqld restart
# ./client/mysql_upgrade -uda_admin -p

You should supply your password of course.

3. PHP 5.3 is the oldest one still available.

4. It works like a charm. Everything I used so far works.

5. DA manages only the DA software and yes, the updates work fine. The OS updates are done by the freebsd-update binary and the ports updates are done through the portmaster binary. They have nothing to with DA. And yes, they are NOT breaking anything.

P.S. My personal advise is to go with PHP-FPM, not the mod_php variant. But it's up to you of course.
 
P.S. My personal advise is to go with PHP-FPM, not the mod_php variant. But it's up to you of course.
1. Why is it better?
2. Will it work with Will that work efficiently with ioncube?
3. We have at least one site that has php pages named .html and there is an entry in the config to make that happen. Can that still work?

I have an ESXi VM on DA on it that isn't doing much. I'm going prep some new base FreeBSD 11.1 base VMs and roll out and give it a whirl.

Thanks TONS for your very valuable time and advice.
 
Last edited:
1. Mod_php is making Apache to work in Prefork mode which is:

A. Inefficient because it forks httpd processes instead of using threads and as a consequence it also does not support HTTP2
B. Eventually insecure and not comfortable for shared hosting environment because all user files are sharing the same credentials (user apache, group apache or similar). That way one user can read files of another and single user php script has no write permissions (for temp files and cache) if the files don't have write permissions for group, etc. This can be fixed with mod_ruid2 (highly recommended) - it will make the main httpd process to run with user root.

In contrast PHP-FPM allows Apache to work in Event mode which is the best one (threaded, supports HTTP2 and optimized for Keep Alive requests). Also each PHP scipt is run with its own user credentials which is both secure and comfortable for the users.

2. Yes, it works fine with ioncube

3. If you install the Htscanner module for Apache, PHP-FPM can be reconfigured via .htaccess the same way as the mod_php can. This means that usually there won't be any problems with migration.
 
Last edited:
Thanks for all of your input.

- On the super busy servers, I will stick with MOD_PHP and PHP 7. They do 146 dynamic pages a second of very dynamic content from both a local database and from around the world. In a video, the PHP author says 7x is a lot faster and less memory intensive than 5.x.

- On the general web server, I will go with your recommendation, but may use 5.x here for compatibility reasons.

- On the one with locked in software, I talked with the owner again. He said he may be able to eliminate that part of the software, so in the meantime, it be on its own VM.

- One thing the video mentioned was Pham for finding PHP code cleaning and version compatibility, but also noticed there are some that also claim to just show you the code that is not compatible with PHP 7 on a site. If you have experience with something good along these lines, let me know.

Thanks TONS!
 
- On the super busy servers, I will stick with MOD_PHP and PHP 7

Before HTTP/2 it was true that mod_php was slighly faster than PHP-FPM. This is no longer the case. Being stuck in prefork mode, now Apache+mod_php is slower than the alternative. PHP-FPM allows Apache to run in Event mode and that way now FPM is actually giving faster performance. So even on super busy servers it's recommended to use PHP-FPM. The mod_php strategy is going to fade-out in history.

One thing the video mentioned was Pham for finding PHP code cleaning and version compatibility, but also noticed there are some that also claim to just show you the code that is not compatible with PHP 7 on a site. If you have experience with something good along these lines, let me know.

Well that's usually a lot of work. Old sites use mysql_* libraries - all must be updated to mysqli_*, - eregi_* which must be updated to preg_*, create_function which must be updated to anonymous function, etc.

Yes, PHP7 is cool but investing time to cleanup old code is not that cool :)

Pham is a nice project but don't expect too much from it.
 
Before HTTP/2 it was true that mod_php was slighly faster than PHP-FPM. This is no longer the case. Being stuck in prefork mode, now Apache+mod_php is slower than the alternative. PHP-FPM allows Apache to run in Event mode and that way now FPM is actually giving faster performance. So even on super busy servers it's recommended to use PHP-FPM. The mod_php strategy is going to fade-out in history.
The last time, for us, it wasn't slightly, it was massive. The servers couldn't couldn't come close to standing up. We tried Event, but it was crazy unstable, and was experimental in Apache 2.2. I tried it with NGINX and that was slower. Threads are much more susceptible to problems with dirty code than processes. Since Apache holds the interpreter in it's context, it doesn't make sense that farming it out would be faster. I noticed that during Rasmus Lerdorf's talk on PHP 7 in March of 2018 at Salzburg, that he uses Pre-Fork where he works. PHP-FPM security advantages make sense. I have a web server or two to update too. I'm game to try it on a busy server because all I would need to do is make a copy of the production VM, change the copy, turn the production one off, and start the PHP-FPM one and see watch what happens.

Well that's usually a lot of work. Old sites use mysql_* libraries - all must be updated to mysqli_*, - eregi_* which must be updated to preg_*, create_function which must be updated to anonymous function, etc. Yes, PHP7 is cool but investing time to cleanup old code is not that cool :)
I did one big site from 5.2->5.3. Dreamweaver's ability to find things across lines worked pretty good for going from POSIX to PCRE. You're right, the 5.4 -> 7.2 changes would require understanding the code you are modifying, which makes that a "whole 'nother kettle of fish". That's why I was hoping to find something that would make it easier to quantify the size of my problem.

Pham is a nice project but don't expect too much from it.
After Rasmus moved to PHP 7, he is getting by with 1/3rd of the servers, and giving better response times. He states the doubling the throughput amounts to 800% greater utility. I was looking for a tool that would quantify the size of my conversion fears. Rasmus says there is no reason not to move to 7 and the code changes should be minor. He hasn't seen the code on our servers. LOL! The easier way out for me would be to have available 5.3 and 7.2 and default them all to 5.3 in the beginning, then fix any 5.2 to 5.3 issues. At least those changes do not require understanding the code.

You have been MASSIVELY helpful! Thanks TONS!
 
Your information about threading and Apache stability is "ancient" (probably from 10 years ago). In Apache 2.4 the default MPM is Event. Let me quote the official Apache HTTPD documentation:

In the case of Unix, the decision as to which MPM is installed is based on two questions:

1. Does the system support threads?

2. Does the system support thread-safe polling (Specifically, the kqueue and epoll functions)?

If the answer to both questions is 'yes', the default MPM is event.

If The answer to #1 is 'yes', but the answer to #2 is 'no', the default will be worker.

If the answer to both questions is 'no', then the default MPM will be prefork.

In practical terms, this means that the default will almost always be event, as all modern operating systems support these two features.

And one more quote which is related to the modern HTTP/2:

HTTP/2 is supported in all multi-processing modules that come with httpd. However, if you use the prefork mpm, there will be severe restrictions.

In prefork mod_http2 will only process one request at at time per connection. But clients, such as browsers, will send many requests at the same time. If one of these takes long to process (or is a long polling one), the other requests will stall.

mod_http2 will not work around this limit by default. The reason is that prefork is today only chosen, if you run processing engines that re not prepared for multi-threading, e.g. will crash with more than one request.

If your setup can handle it, configuring event mpm is nowadays the best one (if supported on your platform).

Of course it's up to you. Have a nice day :)
 
Your information about threading and Apache stability is "ancient" (probably from 10 years ago). In Apache 2.4 the default MPM is Event. Let me quote the official Apache HTTPD documentation: And one more quote which is related to the modern HTTP/2: Of course it's up to you. Have a nice day :)
I had read the official HTTPD docs. Then I go on line and see others asking why pre-fork is faster, then I remember my ancient experience, then I hear the Rasmus's talk on PHP 7 and how he is using pre-fork, then I read...gaah! With all of this conflicting information it leaves me with, "Time to start over and test everything again." As you said, after being frozen in time since FreeBSD 7.2, I definitely can't rely on my experience, LOL! In the mean time, I have decided instead to start with a shared hosting server first due to TLS issues, where I plan to follow your advice and go with PHP-FPM due to its inherent security advantages. I'll never become proficient long-term in this area like you are because it isn't the primary focus of what we do.

I sprung a couple IPs, and I'm going to start the shared hosting one today. Since we use ESXi, I use UFS and my current plan is the following with the percents being what the 7.2s are using on the partitions today:
Virtual Hard Drive: 128GB. (With /home on the end, I can easily extend it later.)
/ - 2 gigs (currently use 16%-26%)
/tmp - 1 gig (use 0%)
/var - 5 gigs (use 30%)
/var/tmp - 1 gig (use 1%)
/usr - 15 gigs (the 7.2s use 28%-45% of this w/old ports tree installed)Maybe should go 20 gigs or 30 gigs
/home - remainder

I'll let you know if I run into any snags.

Again, thanks TONS!!! for all of your help and insights. They've been MASSIVE!
 
Last edited:
I personally make one big partition (/) and only /tmp set to tmpfs (ramdisk).

One tip: when reading articles about prefork, make sure that you are not reading stuff from 2010 :) Keep your list recent and up to date.
 
You caught me at the right time, LOL! I was partitioning. I'll think about if I want to do that before I procede.
 
Last edited:
Partitioning is good if you have many different raid arrays. If you use one, there's no reason to restrict yourself :)
 
Back
Top