MikeL's FreeBSD howto - 11.1 install

This is actually for 12.1-RELEASE.
Note that rcs is no longer installed by default - you'll need to do:
pkg install rcs, then rehash


I'm getting slammed by script kiddy brute force dictionary attacks on 'ssh', 'ftp', 'imap', 'pop3'. I'm trying blacklistd to fix this. See Adding firewall on how to fix this.
[20171226- MikeL]

Sorry, no time to do this right -- just throwing in some gross notes to help jog my memory if I find myself stuck here again...

Dell R710 server, PERC 6, two RAID 5 groups configured for BIOS.
Downloaded 11.1-release ISO, burned CD. (See release 10 howto for CD burn directions.)
Booted server to CD. During install got some error messages about unrecoverable media error, sounded like CD was bad. If I wasn't watching, I might not have seen them, they eventually scrolled off top. Regardless, install seemed to work just fine.
Got worried about the error messages, burned a new CD from same iso file, reinstalled, same error messages. Googled, did not find anything related. Again, install seemed fine, so just went with it.

See 10.0 install for personal customizations. (Ignore stuff about 'bsdintall'.) Install 'emacs24'. Skip 'bind99' install (see below).

Note: 'putty' with SSH->X11, select "Enable X11 forwarding" and put ":0.0" in the location box. Don't forget to 'setenv $DISPLAY=localhost:10.0' on the server. I used to use an older ssh client where this would work with localhost set to the client IP addr - this does not work with putty. Oh, btw I had to change to putty as my old client is now rejected by server with errors about old protocols no longer accepted.

'named' is now 'bind' and is no longer installed by default. Installed that ('pkg install'), started getting bitch messages about that being too old, please update to BIND911. So moral of this part of story is to start with BIND911. [20200319 Now BIND914 - no more TCP_FASTOPEN tweak]
BIND911 now requires some dang kernel tweak or you'll get logspam something about "TCP_FASTOPEN". Gosub build custom kernel.
[20200319 Note that the service command is still 'named', not 'bind' as you might expect.]

Build custom kernel
My previous pages on this are old, take them with a grain of salt.
Had a lot of trouble building kernel. See:
In 62141, do not do the section on '/boot/loader.conf'. This just tells the freebsd loader which directories to list and which to see. If you do not specify, it will simply show what's there. If you did a 'make installkernel', your new kernel is the default 'kernel'. If you did NOT do the 'installkernel', then you would want to mess with this stuff. Also do NOT do the section on '/etc/src.conf' - it gives me parsing error and it doesn't seem to be needed if you simply always specify 'TARGET=' and 'KERNEL='.

First time only:
pkg install subversion
svn checkout http://svn.freebsd.org/base/releng/11.1/usr/src

mkdir /root/kernels
cd /usr/src/sys/i386/conf
(Note: YOURSYSTEMNAME is traditionally done in all uppercase. I use the same name as the DNS name for the box)
cp GENERIC /root/kernels/YOURSYSNAME.i386
ln -s /root/kernels/YOURSYSNAME.i386 YOURSYSNAME

Edit your file /root/kernels/YOURSYSNAME.i386
  options TCP_RFC7413
(Note filename will have dot-architecture - ident does not.)

cd /usr/src
(Note: takes a few mins)
make clean

(Note: takes an hour or so)
(Note: change number to YYYYMMDDxx, year, month, day, attempt that day.)
make buildkernel KERNCONF=YOURSYSTEMNAME TARGET=i386 |& tee /root/kernels/20172600buildkernel.log

(Note: takes a few mins)
(Note: kernconf is kernel ident, not filename - no dot architecture)
(Note: output filename changes to "install" - was "build" in previous - as well as date and sequence)
Once you get a successful complete build:
make installkernel KERNCONF=YOURSYSTEMNAME TARGET=i386 |& tee /root/kernels/20172600installkernel.log
All should be ready, you can check that the install happened by checking the dates on the files in /boot/kernel and make sure it's now.
shutdown -r now

If you get an unbootable kernel, at the loader prompt you should be able to proceed by entering boot kernel.old.

Once running, check which kernel you actually are running with uname -v.
Edit /var/log/dmesg.today. Ignore the 6th line where it gives a path to a GENERIC file - this seems to be the build that the original files were based upon, as opposed to the actual build time and date. Search for error, warning and not. Problems still? Google is your friend.

Now do same steps with /var/log/messages.

Now same steps with /var/log/console - if this file is not there, go back to this section in my release 10 install directions.

I'm getting the same old dang boot error about more swap than recommended, change maxswzone that I was getting in release 10. Tried same stuff as last time, still haven't gotten this to go away yet, but it doesn't seem to have caused any problems so will continue to ignore for now. Have spent unbelievable number of hours googling, rebooting, trying stuff but never got this one fixed.

And you know what? After all this fucking shit, it still hasn't fixed the fucking TCP_FASTOPEN error in the fucking console log from the fucking 'bind' server. Fuck. Fuck. Fuck. Fucking DAYS in the fucking toilet -- days.

Am also seeing and have not figured out:
module_register_init: MOD_LOAD (vesa, 0xc10123d0, 0) error 19
pcib0: _OSC returned error 0x10

Making php sessions work
I spent days trying to figure out why a prefectly functional .php application would not work on the new system. There were several things I had to do to the old script:
My script would seem to run, but as soon as it called out of the initial function to a lower function, there would be no $_SESSION variable. Web searches came up with things like "make a script that does nothing but call phpinfo" - I did this, but did not know what to expect. Making that same script on a machine where php does work, I learned that there was an entire section named "session" that simply was not there on my broken server. I tried reinstalling the package, as comments suggested it may have been compiled with some switch to disable session - this did not fix it. (BTW I was installing via "pkg".)
Using command line php -i, by the way (appears to) give you the same info as a script that just says phpinfo();. Web searches claimed that it does not show session info - from my experience, this is false - on my system when the session was broken, you could do php -i | grep -i session and get nothing. Now that the system is working, this will yield a list of some 20-30 values.
Things I changed in the /usr/local/etc/php.ini file:
So how did finally make it work? Ridiculously simple. Fucking stupid shit php - gawd I fucking hate fucking php - you must manually create the session.save_path directory.
mkdir /tmp/php_sess
chmod 700 /tmp/php_sess
chown www /tmp/php_sess
chgrp wheel /tmp/php_sess


At system boot, I am seeing the following log message:

Starting powerd.
powerd: no cpufreq(4) support -- aborting: No such file or directory
/etc/rc: WARNING: failed to start powerd
My system is a Dell R710. I found the fix at: (link). In a nutshell, edit your /boot/device.hints file. The last two lines in my file were:

Change these two lines to be ="1" instead of 0. If you do not have these two lines, add them.

Copyright © 1995-2023 Mike Lempriere (running on host pedicel)