As stated in my last post, my server died several months ago, and I decided to take that unfortunate opportunity to gain some Unix experience by installing FreeBSD on its replacement. Although this server has been installed for several months, the main reason that this weblog has been down is because of multiple configuration issues with FreeBSD that, frankly, I think should have worked Out Of The Box.
A friend of mine who is adamant about FreeBSD told me to name this inevitable post "FreeBSD from a gentoo user's perspective." It's true that my desktop's distro of choice has been gentoo for several years, but I'm no ricer. I love gentoo because I love portage--the gentoo package manager which is, in fact, a derivative of FreeBSD's ports package manager. I don't care much for any package manager that doesn't give you the option to change compile-time options. Anyway, I'm going to try my best to leave any bias-ness I may have behind me as I work through the multitude of flaws that I encountered with setting up a FreeBSD webserver.
As a gentoo user, I can understand the expected perils of using a system that is designed to have both a minimized footprint and that has been hardened for security. I understand that common packages like wget and unzip won't necessarily be included in the default install (which, in FreeBSD, they're not). That's all a bit annoying, but I sure as hell won't hold it against FreeBSD. What I will hold against them, is when after I install a popular application via their esteemed package manager (which I was actually looking forward to), the package is broken OOTB. I am even somewhat accepting of package requiring configuration before it can run--that isn't a bug, it's just not a very friendly system. But I don't condone any system that requires troubleshooting to fix an error with a freshly installed package before it can even run.
Just to make that last point perfectly clear, and to prioritize my issues so that this post doesn't sound too rant-like (by bitching about things that aren't at FreeBSD's fault, but that are--in fact--due to my own ignorance, unfamiliarity with the system, and general laziness), I've separated my complaints into 2 sections: Serious Issues and Minuscule Annoyances.
Serious Issues
As stated above, this section is for serious issues that I encountered during the install/configuration(/debug) process of FreeBSD. It mainly consists of very popular applications that didn't work OOTB due to errors in their default configurations that I had to track down and fix before they would even be usable.
Apache Default Config Will Not Work OOTB
There's something up with the default FreeBSD kernel that prevents a fresh Apache install from working properly. I found a work-around here:
Once I got that fixed, I could start my apache server just fine, but it wasn't responding to HTTP requests. I eventually dug into the logs and found that on startup, I was getting the following error:
[Thu Dec 25 22:07:14 2008] [alert] (EAI 8)hostname nor servname provided, or not known: mod_unique_id: unable to find IPv4 address of "neo.matrix" Configuration Failed
I never bothered to find a fix. My FreeBSD buddy just decided to comment out the line in the httpd.conf file that loaded the module that was bitching. ie she changed:
LoadModule unique_id_module libexec/apache22/mod_unique_id.so
...to...
#LoadModule unique_id_module libexec/apache22/mod_unique_id.so
That band-aided the issue, but what the hell is the real problem? Also, what security holes do you open when you arbitrarily leave out certain modules from the apache configuration? I don't like it. Why does the default httpd.conf file have errors in it?
IMHO, a package as popular as Apache should certainly be immediately usable with the default package's configuration after a fresh install. No excuses for this.
MySQL Permissions Errors OOTB
OK, so I installed the mysql-server package from ports. I went ahead and tried to start it with the rc.d script, and everything appeared to be working great. But, when I tried to connect to it, I kept getting errors:
[root@neo ~]# /usr/local/etc/rc.d/mysql-server start Starting mysql. [root@neo ~]# mysql -u root ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2) [root@neo ~]# /usr/local/bin/mysqld_safe Starting mysqld daemon with databases from /var/db/mysql STOPPING server from pid file /var/db/mysql/neo.matrix.pid 081225 16:43:31 mysqld ended
I did a tail -f on the mysql log file to determine the issue, and I got the following when starting the server:
[root@neo ~]# tail -f /var/db/mysql/neo.matrix.err 081225 16:43:31 mysqld started 081225 16:43:31 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295 081225 16:43:31 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295 081225 16:43:31 InnoDB: Operating system error number 13 in a file operation. InnoDB: The error means mysqld does not have the access rights to InnoDB: the directory. InnoDB: File name ./ibdata1 InnoDB: File operation call: 'create'. InnoDB: Cannot continue operation. 081225 16:43:31 mysqld ended
FreeBSD stores its database data in /var/db/mysql/. Turns out that the default permissions on these files are owned by root:wheel. In order for mysql to function properly, these need to be owned by mysql, so I did the following:
[root@neo /var/db]# ls -lah /var/db/mysql total 14 drwx------ 4 root wheel 512B Dec 25 16:56 . drwxr-xr-x 9 root wheel 512B Dec 25 15:39 .. drwx------ 2 root wheel 1.5K Dec 25 15:39 mysql -rw-rw---- 1 mysql wheel 4.3K Dec 25 16:56 neo.matrix.err drwx------ 2 root wheel 512B Dec 25 15:39 test [root@neo /var/db]# chown -R mysql:mysql /var/db/mysql
...and tried to restart it again. This time, the /var/db/mysql/neo.matrix.err log spat out:
081225 17:03:52 mysqld started 081225 17:03:52 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295 081225 17:03:52 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295 InnoDB: The first specified data file ./ibdata1 did not exist: InnoDB: a new database to be created! 081225 17:03:52 InnoDB: Setting file ./ibdata1 size to 10 MB InnoDB: Database physically writes the file full: wait... 081225 17:03:53 InnoDB: Log file ./ib_logfile0 did not exist: new to be created InnoDB: Setting log file ./ib_logfile0 size to 5 MB InnoDB: Database physically writes the file full: wait... 081225 17:03:53 InnoDB: Log file ./ib_logfile1 did not exist: new to be created InnoDB: Setting log file ./ib_logfile1 size to 5 MB InnoDB: Database physically writes the file full: wait... InnoDB: Doublewrite buffer not found: creating new InnoDB: Doublewrite buffer created InnoDB: Creating foreign key constraint system tables InnoDB: Foreign key constraint system tables created 081225 17:03:53 InnoDB: Started; log sequence number 0 0 081225 17:03:53 [Note] /usr/local/libexec/mysqld: ready for connections. Version: '5.0.67' socket: '/tmp/mysql.sock' port: 3306 FreeBSD port: mysql-server-5.0.67
The InnoDB: Operating system error number 13 in a file operation. error was no longer appearing, so I tried to reconnect, and:
[root@neo /var/db]# mysql -u root Welcome to the MySQL monitor. Commands end with ; or g. Your MySQL connection id is 1 Server version: 5.0.67 FreeBSD port: mysql-server-5.0.67 Type 'help;' or 'h' for help. Type 'c' to clear the buffer. mysql>
Success!
In my trials of trying to come to the above solution, I ran across one website bashing ports for its terrible default installations:
To be quite honest you may have better luck downloading and installing MySQL yourself. It's very rare I install anything from the ports on FreeBSD or apt repositories on Debian, simply because you have little (if any) control over what goes on. At least if you do it yourself you know how you're setting the system up. That's just from personal experience.
As with Apache, Mysql is an extremely common linux application. After a fresh install from ports, the permissions can be expected to be wrong on all the mysql files so that the server cannot be started. This is extremely careless on the part of the ports developers. Again, there's no excuses for this. At least a basic, hardened mysql server should be startable immediately after a fresh install from ports.
Minuscule Annoyances
Finally, FreeBSD had a bunch of little things that kept hindering my productivity throughout the entire install/configuration(/debug) process. I don't hold anything in this section against FreeBSD. It's mostly stuff that resulted simply from my ignorance, unfamiliarity with Unix, and my own laziness. Other items in this section may be a result of FreeBSD wanting to maintain a small footprint or wanting to maximize the security of their default install by hardening certain aspects--thereby limiting functionality; for those items I applaud FreeBSD, but they're still worth mentioning.
No "Go Back" in Installer
Don't get me wrong, I love the command line. My music player of choice is alternate install CD for my Ubuntu disks. I think it's great that most distros now have GUI-based live install CDs so that you can look at pr0n or whatever while you install, but I honestly prefer a simple text-based install process. FreeBSD gave me this.
The issue was that I couldn't fucking go back. I think I had to install the OS 4 times until I didn't accidentally zip past a setting that wasn't setup correctly. Sure, I could have manually made the change to the necessary config files after I was up and running, but I don't know enough about Unix to do that--and I might miss something.
I know it's a second-thought to create a back-button. I could understand a newbie programmer forgetting to create something like this, but c'mon Berkeley. Honestly.
Delete Key is Backspace
I don't know how I ever fixed this, but for the longest time my "delete key" didn't function correctly. In case you didn't know, let me explain this to you (if you really need this explanation, you're retarded and shouldn't be at this blog): a backspace removes a character to the left of the insertion point; a delete key removes the character to the right of the insertion point. In FreeBSD, my delete key would remove the character from the left of the insertion point. --very annoying
Everything seems to be working OK in BASH, now. In CSH, however, my delete key inserts a tilde (~). What the fuck?
Crippled vi
For one, I can't backspace in vi. Ever tried to type something without being able to backspace? If you've used Solars you have. Welcome to fuckin' Unix. I'm sure this is a configuration issue somewhere, but I didn't have the time to google it, so I just used the x key instead.
Also, for some reason, I can't select lines. If I type V (a capital v should select the line), I get a friendly message: V isn't a vi command. o rly? Tell that to the hundreds of other machines I've used vi on who know how to properly handle a V. Whatever. I did most of my work over SSH on another machine, so I just copied and pasted from my terminal window. Still annoying, though.
C Shell Inferiority
The default shell is CSH. I'm used to BASH. My biggest gripe about CSH is that tab-completion doesn't display more than one file. In BASH, for example, if you type /etc/p, it will show you all of the files & directories in /etc/ that start with a p. In CSH, this will just beep at you. Even my FreeBSD friend replaces CSH with ZSH. But, hey, I'm sure CSH contributes to the small footprint of FreeBSD. Maybe it's even more secure *shrug*.
Conclusion
There were several other issues that I had to overcome to properly configure wordpress on this server, but this post is already long enough. Overall, I'm very unsatisfied with the OOTB installation and configuration of packages via FreeBSD's ports.
In gentoo, portage not only compiles new packages, it also changes permissions and preforms any other necessary task to ensure that your package will be at least minimally working OOTB. Even still, it's one thing to have to add a line to a configuration file after a package is installed, but it's something else to have to comment out some misbehaving line or recursively change the default permissions on an entire database's data directory.
FreeBSD: I am not impressed.
Related Posts
Hi, I’m Michael Altfield. I write articles about opsec, privacy, and devops ➡
Leave a Reply