Linked by Nathan Mace on Tue 19th Mar 2002 17:21 UTC
FreeBSD Most tech savvy geeks can work their way through a FreeBSD install, even if they have no prior UNIX experience. However installing an OS and configuring an OS are two totally different things. This article is targeted towards anyone who might be wondering about FreeBSD, but doesn't know what to do with it after they install it. This isn't then end-all be-all of FreeBSD howto's. Just some of the simple stuff. Update: Some of the readers of OSNews have emailed me concerning corrections that need to be made in this article. Dig in (third page) for more.
Order by: Score:
Nice Link
by SimBad on Tue 19th Mar 2002 18:58 UTC

Really usefull information and well worth a read.

Sim

FreeBSD
by SimBad on Tue 19th Mar 2002 19:00 UTC

Oh I forgot Eugenia, the link to freeBSD dosn't work

Sim

Nice.
by FUD on Tue 19th Mar 2002 19:14 UTC

Nice article :0)

This is where FreeBSD needs more work
by mra on Tue 19th Mar 2002 19:37 UTC

I was just configuring a new FreeBSD 4.5 system last night along with an OpenBSD 3.0 system and was running into this issue.

FreeBSD 4.5 and OpenBSD 3.0 were released before the OpenSSH / zlib bugs were found so those two things need to be patched before the systems could be considered safe to connect to the Internet. In OpenBSD this involved cvsing the latest patch cluster for the system and rebuilding the affected binaries. It wasn't this easy on FreeBSD. I had to look up the individual advisories and download each patch from different paths on the server because I couldn't find anything on their site as to how to do it any other way.

This is one of the places where OpenBSD's strict adherance to procedure and documentation made updating the OS much easier then it was under FreeBSD.

Re: This is where FreeBSD needs more work
by Anonymous on Tue 19th Mar 2002 20:21 UTC

Easy way to fix freeBSD's system is to sync with the cvsup servers (ports tree for OpenSSH and the source tree for the rare occassion a system lib has an error) then make/make install. It's not overtly complicated.

Is it just me?
by Anthony on Tue 19th Mar 2002 20:41 UTC

Is it just me or dosn't this seem like a hell of a lot of work just to keep your system up to date? Don't get me wrong, their are certain things I absolutely love about FreeBSD, but I think that overall this is its biggest downfall. I've used FreeBSD in the past and this was the part that made me change to Linux. Keeping FreeBSD updated is a lot of work. Most Linux/Binary distributions make this easier with a simple package updater. If FreeBSD came up with an easier way to keep it updated I would definetly switch full time. I heard they're going to update sysinstall for this very reason but I'm not 100% sure about that.

RE: is it just me?
by Nathan on Tue 19th Mar 2002 20:53 UTC

how can you say that keeping freebsd updated is hard & complicated? all you have to do to keep the system up to date is cvsup the source, compile it, and install it. with the apps it's even easier. just cvsup the ports tree, and run portupgrade on the app that you want updated

RE: Nathan
by Anthony on Tue 19th Mar 2002 21:22 UTC

I don't believe I said complicated or hard. I did mean it's a lot of work (time consuming).

When compared to:
"apt-get --dist-upgrade" <- that's it now you're updated

sysinstall is a great example
by mra on Wed 20th Mar 2002 00:06 UTC

from `man sysinstall`

This utility is a prototype which lasted several years past its expiration date and is greatly in need of death.

and

This version of sysinstall first appeared in FreeBSD 2.0.

The FreeBSD people are aware of these sort of user issues. Don't get me wrong, I'd prefer that they spend their time making the network stack faster then making the install easier, but I think people are justified in saying that the install and update procedures are too difficult in FreeBSD.

Try Gentoo Linux!
by DaCh on Wed 20th Mar 2002 03:40 UTC

Gentoo's ports-based packaging system is rediculously easy. To install the latest kde, for instance, and all dependencies in one single command, type "emerge kde". That's it.

Re: Try Gentoo Linux!
by Anonymous on Wed 20th Mar 2002 04:59 UTC

But that's not it. I did a few ports for gentoo back around rc 4/5; and it's not that easy. Portage failed often, and required major structural redesign. And version conflicts are abound. Daniel while charasmatic and a good writer doens't seem to have a clear plan of what needs to be in Portage.

Anthony: I don't see how
"cvsup [cvsupfile] && cd [dir] && make install"
is difficult. The ports system is updated regularly,

I tried Debian, and I don't really see why everyone likes it so very much. The installer managed to mess up my network card. I couldn't use dselect [it's just irritating].
The only linux distribution I particularly liked was Slackware, but it really needed something like ports.




FreeBSD init scripts
by Rick Morris on Wed 20th Mar 2002 07:16 UTC

The article is a nice overview, but is rather thin on explanation of the FreeBSD init system. He dismisses the core init stuff as "several rc.*" files. These are critical files, and should be learned by any serious FreeBSD admin. The main configuration for standard system startup is controlled through a file called /etc/rc.conf, which doesn't actually have the startup scripts, but contains user overrides FROM the default startup inside /etc/defaults/rc.conf. This is a very smart concept, which shields the user from complexity, and shields the system from having a broken startup file. Any changes you make to startup options in /stand/sysinstall will appear in /etc/rc.conf, also. It also contains settings for your NIC cards.

And I know that /usr/local/etc/rc.d is the traditional custom startup script area, for non-core stuff, but FreeBSD also provides for a nice generic startup script called /etc/rc.local. If it is not there, just create it, and any commands you put in there will be run as the system boots.

Re : FreeBSD init scripts
by Julien GABEL on Wed 20th Mar 2002 08:52 UTC

/etc/rc.local is deprecated. Don't use it.

FreeBSD updating
by JAVE on Wed 20th Mar 2002 09:08 UTC

First off, /stand/sysinstall works, although it's not pretty. I don't care for a flashy graphical install tool, and you /can/ use the cursor keys to select stuff, so it could be worse :-)

The way a system upgrade is explained is horribly complicated.
this works for me (and is how the handbook tells you to do it too):

cvsup -g L2 stable-supfile

cd /usr/src && make -j4 buildworld && make installworld
make buildkernel KERNCONF=<KERNALNAME>
shutdown now
cd /usr/src
make installkernel KERNCONF=<KERNELNAME>
mergemaster
reboot

As for checking ports:

portversion -l'<'
(add a -v if you want the version numbers)
and then portupgrade -r <basename> will suffice
(so just 'portupgrade vim' for vim.)

After the struggle I had with RPM based Linux distros, this is heaven.

Nice article but a few corrections needed
by Anonymous on Wed 20th Mar 2002 13:05 UTC

This is certainly something that needed an article written about. Newbies very often show up after installing their new systems and wonder what to do next, and especially how to upgrade. Nice work.
However, slightly wrong information just adds to the general level of confusion and sometimes gets people in trouble, then they decide they hate FreeBSD because something didn't work for them.
The recommended way to build a new world and kernel is this:
To update from 4.0-RELEASE or later to the most current
4.x-STABLE
----------
make buildworld
make buildkernel KERNCONF=YOUR_KERNEL_HERE
make installkernel KERNCONF=YOUR_KERNEL_HERE
reboot (in single user)
make installworld
mergemaster
reboot
(Taken straight from /usr/src/UPDATING, which is required reading for upgraders.) Doing as you wrote will work most of the time but this way is supposed to work *all* of the time (and if you do it some other way and have trouble, people will just tell you to do it again this way).

The easiest and most effective way to upgrade ports is this:
cvsup [supfile]
portsdb -Uu
portupgrade -a

portsdb in this usage updates the ports INDEX file so that you don't have to wait for a new one to have portupgrade see that there are new ports. (It also takes a while; 10 min on a K7-1.33G and 1 hr on a P-166. Not to mention that you can't cut some of the ports out easily if you do this because make_index will complain about it.)
The -a flag to portupgrade means "all", it will just upgrade everything that needs it, keeping dependencies straight and doing no more than necessary. (Great utility, absolutely. Many thanks to Akinori MUSHA-san, the author of the portupgrade suite.)

It may also be useful to use the -s flag to cvsup (for both ports and sources), depending on whether you like to muck around with the files you download. See cvsup's man page for details.

Missing something?
by Anthony on Wed 20th Mar 2002 16:04 UTC

Aren't you missing the part were you have to copy the Generic kernel, edit it again, and then compile it. This is the part that really annoyed me. You can't just keep a copy of your modified kernel and keep recompiling form that one because the kernel may have changed. So you have to copy the Generic, and re-edit everytime you want to update. That was a real pain and time consuming. Again, I never said it was difficult, it definetly is not dificult, just time consuming.

For example, you can't really do an update every night, thats just crazy. What about if you needed to update, 10, 20, 50 servers, again, crazy. You could join the announce mailing list and only do the updates needed for security concerns and then do a make world (to keep you're system updated) once a week. But I found that everytime I needed to do a security update I felt I might as well just do a make world while I'm at it. Again, this is extremely time consuming.

I love FreeBSD, I have a server at home that used to run FreeBSD but now is running Linux. I would switch back in a second if they could come up with a better way to keep the system updated. With my linux box; I'm subscribed to the mailing list, when an announce comes in about a bug or a security risk, I just have to update that one binary package (and possibley its dependencies but that is take care of by the package updater) and I'm done. I don't even need to be on the mailing list, I could just have the package updater run every night to check, if there is something that needs to be updated, and have it email me to let me know. I could also have it update automatically at night without my intervention (though I would not recommend this).

I'm saying all this from personel experience. I've used them both and without a dought FreeBSD is my favorite overall. But I felt I had to switch because of the hassle I was going throught all the time just to keep my system updated. Once more, not dificult, just time consuming.

RE: Missing Something
by Anonymous on Wed 20th Mar 2002 19:18 UTC

i don't know about anyone else, but as far as the kernel config file goes, i made a copy of GENERIC, edit it to suit my needs, and then when i cvsup the source i use my edited conf file to make the new kernel. i've been using freebsd for almost a year, and i've been using the same kernel file the whole time. i upgrade to the latest stable about once a month. it's not required that you re-edit the generic file everytime you want to upgrade

RE: Missing Something
by Anonymous on Wed 20th Mar 2002 19:21 UTC

yes, i'll agree that "make buildworld" takes awhile, expecially on slow machines, so why not build it once on a fast machine and share it out via NFS to the slow machines??

upgrading
by Ken on Wed 20th Mar 2002 19:33 UTC

I know that the manual says that you should "shutdown now" before installing world and kernel, but I just want to tell all the BSD newbies that this is completely unnecessary. I *never* reboot into single-user mode to installworld or installkernel with any of my production machines. I just:

make -j4 buildworld && make buildkernel KERNCONF=MYKERNEL && make installworld && make installkernel KERNCONF=MYKERNEL && cp -Rp /etc /etc.old

(-j4 means run 4 threads instead of one. some of my boxes are quad xeons... also, always backup /etc!)

then I come in later, do mergemaster, and then:

at 0400
shutdown -r now
^D

... and I never worry about coming in in the morning to find that the machine can't boot. unlike what happens with linux 75% of the time.

about having to redo your kernel file
by Ken on Wed 20th Mar 2002 19:36 UTC

I keep a file "/usr/src/sys/i386/conf/include" that has all my necessary kernel options. then I:

cp GENERIC MYKERNEL

cat include >> MYKERNEL

... I hated doing it the "hard" way too.. =)

Very interesting ideas
by Anthony on Wed 20th Mar 2002 21:02 UTC

Thanks for the feedback on my comments. I may give FreeBSD another shot.

Some advice
by Per-Arne Holtmon AkÝ on Wed 20th Mar 2002 22:32 UTC

After reading the article and the comments, I felt I had to make a comment too.

First thing is about the way to do an upgrade. While doing just a 'make world kernel KERNCONF=[whatever]' does work, it can be dangerous, especially when we're talking about major version upgrades (i.e., 3.x -> 4.x, 4.x -> 5.x). The described procedure in /usr/src/UPDATING is the recommended way for several reasons, the biggest being binary incompability. I ran into this when I was still a n00b and upgrading from 3.x to 4.x, and I built and installed world before even thinking of the kernel. Oops. It seemed that the 3.x kernel was unable to run 4.x binaries, which I found out the hard way when the installworld crashed half-way, having replaced almost all the critical binaries with 4.x binaries. As said, I still had the old 3.x kernel, and any new binary that I tried to run, crashed with a SIGSEG (#11). After beating the machine around for some hours, I gave up and started to think about what had happened. When I realized that I needed a reinstall to fix the broken machine, I got quite mad, as this was the only computer I had working at the time, and I was sitting on ISDN. Yuck. After downloading the new -RELEASE ISO, I got on and reinstalled, which fixed it.

Consider this as a warning. The safest way IS with an installkernel and consequent reboot to single mode before installworld. I also know some other people who have had the same, not all too great, experience.

The other thing I see mentioned is that you have to re-edit the kernel configuration file each time you cvsup, which is as someone anonymous pointed out, not necessary. You can keep your old kernel configuration file for quite long, although I would recommend checking it every now and then, especially when there are major or minor version upgrades in the progress. A simple way would be to make two copies of the GENERIX file, one which you rename to whatever is you preferrence, the other something like GENERIC.old (or whatever). By doing this, you can use the second, non-modified version of the GENERIC file (GENERIC.old) to diff against the possibly updated official GENERIC file to see what differences there are.

Third and last point is that building world and the respective kernels for the other machines on one fast machine and sharing it through NFS is quite a time-saver, since a dual 1.2GHz Athlon MP will use about 50 minutes on one buildworld and one buildkernel, while a 486 will take a full 24 hours or so. There are some pitfalls here too, the biggest I've encountered is firewalls. If you have a firewall (say ipfw) on the clients that're installing from the NFS server, with a default-to-deny stance in the kernel, you can run into some problems with /sbin/ipfw and the kernel (the new one you just installed) being out-of-sync, which will cause /sbin/ipfw to seg.fault when you're trying to run it. And with a default-to-deny stance, you're pretty much scr****. This is a bit contradictory to what I previously said, but first doing an installkernel, and before the reboot, then do the installworld will go around the particaular problem described above.

One last thing I could mention is that in the default make.conf (/etc/defaults/make.conf) there are some entries starting with SUP_. If you copy these and modify them for your needs, all you need to do when cvsup'ing is 'cd /usr/src && make update', which will update the source tree, the ports tree and the docs tree, in addition to running cvsup on the other optional sup-files. This makes being even more lazy simpler. ;)

Anyway, this comment is getting quite long, so I think I'll call it a day here. I hope someone find my comment useful.

I just build a new GENERIC kernel first
by DaN on Thu 21st Mar 2002 00:16 UTC

and after that my customized kernel. Looking through the new GENERIC is always recommended and compiling one is too, just in case your cust kernel doesnt boot or something. If dealing with a remote box, well I think you can stick it into one of the boot config files as well as a copy of your former kernel. Than you might quite safely reboot.

Note that this is about reboot after installworld and mergemaster (upgrade ports after reboot). Can't reboot single user mode and then ssh into the remote box so no try-outs of new kernels in that case. Finish and reboot.

Besides, you should note that you can do binary upgrades from relase to release and then track the RELENG_4_5 branch (and later 4_6, 4_7, etc) to only get bigfixes and security patches, instead of RELENG_4 (= fBSD-STABLE).

If a fix is needed you either apply patch, or cvsup and then either only compile and install that certain part (if it's easily found) or buils/install world. No fiddling with kernels needed then (unless of course there's a kernel fix).

To you ANTI cvsup/ Anti FreeBSD people
by Michael V on Sat 23rd Mar 2002 08:39 UTC

You dont need to use CVSup to keek your programs update.
Alot of hardcore linux/anti FreeBSD users seem to say source building is dumb. Even if you choose to think that, with FreeBSD you can use pkg_add -r command to install binary installs of programs AND ALL ITS DEPENDENCES AUTOMATICALLY.
All you do is find your local FreeBSD mirror.
then add the PACKAGESITE enviroment for your csh or bash shell.So I put
setenv PACKAGESITE ftp://mirror.aarnet.edu.au/raid/2/freebsd/ports/i386/packages-4-st...
In my /root/.cshrc
You can see it with the "env" command
%env
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/loc al/bin:/usr/X11R6/bin:/root/bin
blah,blah
PACKAGESITE=ftp://mirror.aarnet.edu.au/raid/2/freebsd/ports/i386/packages-4-st...
Now if I wanted to install VIM and all its deps of the very latest version of VIM I just do
pkg_add -r vim
and it fetchs it and installs all the deps automatically
Fetching ftp://mirror.aarnet.edu.au/raid/2/freebsd/ports/i386/packages-4-st...... Done.
Fetching ftp://mirror.aarnet.edu.au/raid/2/freebsd/ports/i386/packages-4-st...... Done.
Fetching ftp://mirror.aarnet.edu.au/raid/2/freebsd/ports/i386/packages-4-st...... Done.
Fetching ftp://mirror.aarnet.edu.au/raid/2/freebsd/ports/i386/packages-4-st...... Done.
Fetching ftp://mirror.aarnet.edu.au/raid/2/freebsd/ports/i386/packages-4-st...... Done.
Fetching ftp://mirror.aarnet.edu.au/raid/2/freebsd/ports/i386/packages-4-st...... Done.
Fetching ftp://mirror.aarnet.edu.au/raid/2/freebsd/ports/i386/packages-4-st...... Done.

If I didn't want the latest builds I would set the environment to
ftp://mirror.aarnet.edu.au/raid/2/freebsd/ports/i386/packages-4.5-...

Re: To you ANTI cvsup/ Anti FreeBSD people
by Anthony on Mon 25th Mar 2002 19:37 UTC

You've forgotten that many ports are not converted to a package binary. Also what you just explained is how to install new packages not how to keep your entire system updated. One more thing you missed is that even if this worked it would only update the port/packages not the FreeBSD source (e.g. /usr, /etc, kernel, etc) the only way to do this is to cvsup the source and then do a make world. In comparison to what you've just explained I would rather go with a cvsup ports and then use portsupgrade, that is the easiest way to go but that was not the issue.