The primary configuration file is /etc/defaults/rc.conf (see rc.conf(5)) System startup scripts such as /etc/rc and /etc/rc.d (see rc(8)) just include this file. Do not edit this file! Instead, if there is any entry in /etc/defaults/rc.conf that you want to change, you should copy the line into /etc/rc.conf and change it there.
For example, if you wish to start named, the included DNS server, all you need to do is:
# echo named_enable="YES" >> /etc/rc.conf
To start up local services, place shell scripts in the /usr/local/etc/rc.d directory. These shell scripts should be set executable, and end with a .sh.
Use the adduser(8) command, or the pw(8) command for more complicated situations.
To remove the user, use the rmuser(8) command or, if necessary, pw(8).
This is normally caused by editing the system crontab (/etc/crontab) and then using crontab(1) to install it:
# crontab /etc/crontab
This is not the correct way to do things. The system crontab has a different format to the per-user crontabs which crontab(1) updates (the crontab(5) manual page explains the differences in more detail).
If this is what you did, the extra crontab is simply a copy of /etc/crontab in the wrong format it. Delete it with the command:
# crontab -r
Next time, when you edit /etc/crontab, you should not do anything to inform cron(8) of the changes, since it will notice them automatically.
If you want something to be run once per day, week, or month, it is probably better to add shell scripts /usr/local/etc/periodic, and let the periodic(8) command run from the system cron schedule it with the other periodic system tasks.
The actual reason for the error is that the system crontab has an extra field, specifying which user to run the command as. In the default system crontab provided with FreeBSD, this is root for all entries. When this crontab is used as the root user's crontab (which is not the same as the system crontab), cron(8) assumes the string root is the first word of the command to execute, but no such command exists.
10.4. Why do I get the error, “you are not in the correct group to su root” when I try to su to root?
This is a security feature. In order to su to root (or any other account with superuser privileges), you must be in the wheel group. If this feature were not there, anybody with an account on a system who also found out root's password would be able to gain superuser level access to the system. With this feature, this is not strictly true; su(1) will prevent them from even trying to enter the password if they are not in wheel.
To allow someone to su to root, simply put them in the wheel group.
10.5. I made a mistake in rc.conf, or another startup file, and now I cannot edit it because the filesystem is read-only. What should I do?
When you get the prompt to enter the shell pathname, simply press ENTER, and run mount / to re-mount the root filesystem in read/write mode. You may also need to run mount -a -t ufs to mount the filesystem where your favorite editor is defined. If your favorite editor is on a network filesystem, you will need to either configure the network manually before you can mount network filesystems, or use an editor which resides on a local filesystem, such as ed(1).
If you intend to use a full screen editor such as vi(1) or emacs(1), you may also need to run export TERM=cons25 so that these editors can load the correct data from the termcap(5) database.
Once you have performed these steps, you can edit /etc/rc.conf as you usually would to fix the syntax error. The error message displayed immediately after the kernel boot messages should tell you the number of the line in the file which is at fault.
Please have a look at the Handbook entry on printing. It should cover most of your problem. See the Handbook entry on printing.
Some printers require a host-based driver to do any kind of printing. These so-called “WinPrinters” are not natively supported by FreeBSD. If your printer does not work in DOS or Windows NT® 4.0, it is probably a WinPrinter. Your only hope of getting one of these to work is to check if the print/pnm2ppa port supports it.
Please see the Handbook section on using localization, specifically the section on console setup.
The following is an excerpt from a post to the freebsd-current mailing list.
|
The “can't assign resources” messages indicate that the devices are legacy ISA devices for which a non-PnP-aware driver is compiled into the kernel. These include devices such as keyboard controllers, the programmable interrupt controller chip, and several other bits of standard infrastructure. The resources cannot be assigned because there is already a driver using those addresses. |
||
--Garrett Wollman
<[email protected]>, 24 April
2001 |
||
It is possible that your kernel is not configured to use quotas. If this is the case, you will need to add the following line to your kernel configuration file and recompile:
options QUOTA
Please read the Handbook entry on quotas for full details.
Do not turn on quotas on /.
Put the quota file on the filesystem that the quotas are to be enforced on, i.e.:
Yes, FreeBSD supports System V-style IPC, including shared memory, messages and semaphores, in the GENERIC kernel. In a custom kernel, enable this support by adding the following lines to your kernel config.
options SYSVSHM # enable shared memory options SYSVSEM # enable for semaphores options SYSVMSG # enable for messaging
Recompile and install your kernel.
Sendmail is the default mail-server software for FreeBSD, but you can easily replace it with one of the other MTA (for instance, an MTA installed from the ports).
There are various alternative MTAs in the ports tree already, with mail/exim, mail/postfix, mail/qmail, and mail/zmailer being some of the most popular choices.
Diversity is nice, and the fact that you have many different mail-servers to chose from is considered a good thing; therefore try to avoid asking questions like “Is Sendmail better than Qmail?” in the mailing lists. If you do feel like asking, first check the mailing list archives. The advantages and disadvantages of each and every one of the available MTAs have already been discussed a few times.
Do not panic! Restart the system, type boot -s at the Boot: prompt to enter Single User mode. At the question about the shell to use, hit ENTER. You will be dropped to a # prompt. Enter mount -u / to remount your root filesystem read/write, then run mount -a to remount all the filesystems. Run passwd root to change the root password then run exit(1) to continue booting.
If you are using syscons (the default console driver) build and install a new kernel with the line
options SC_DISABLE_REBOOT
in the configuration file. If you use the PCVT console driver, use the following kernel configuration line instead.
options PCVT_CTRL_ALT_DEL
Use this perl command:
% perl -i.bak -npe 's/\r\n/\n/g' file ...
file is the file(s) to process. The modification is done in-place, with the original file stored with a .bak extension.
Alternatively you can use the tr(1) command:
% tr -d '\r' < dos-text-file > unix-file
dos-text-file is the file containing DOS text while unix-file will contain the converted output. This can be quite a bit faster than using perl.
Use killall(1).
The error comes from the Kerberos distributed authentication system. The problem is not fatal but annoying. You can either run su with the -K option, or uninstall Kerberos as described in the next question.
To remove Kerberos from the system, reinstall the bin distribution for the release you are running. If you have the CDROM, you can mount the cd (we will assume on /cdrom) and run
# cd /cdrom/bin # ./install.sh
Alternately, you can remove all MAKE_KERBEROS options from /etc/make.conf and rebuild world.
FreeBSD 5.X and beyond use the devfs(8) device-on-demand system. Device drivers automatically create new device nodes as they are needed, obsoleting /dev/MAKEDEV.
If you are running FreeBSD 4.X or earlier and /dev/MAKEDEV is missing, then you really do have a problem. Grab a copy from the system source code, probably in /usr/src/etc/MAKEDEV.
If you have lots of telnet, ssh, X, or screen users, you will probably run out of pseudoterminals. Here is how to add more:
Build and install a new kernel with the line
pseudo-device pty 256
in the configuration file.
Run the commands
# cd /dev
# sh MAKEDEV pty{1,2,3,4,5,6,7}
to make 256 device nodes for the new terminals.
Edit /etc/ttys and add lines for each of the 256 terminals. They should match the form of the existing entries, i.e. they look like
ttyqc none network
The order of the letter designations is tty[pqrsPQRS][0-9a-v], using a regular expression.
Reboot the system with the new kernel and you are ready to go.
There is no snd device. The name is used as a shorthand for the various devices that make up the FreeBSD sound driver, such as mixer, sequencer, and dsp.
To create these devices you should
# cd /dev # sh MAKEDEV snd0
Note: You can omit this step if you are running FreeBSD 5.0-RELEASE or newer with devfs(5) enabled.
Go into single user mode and then back to multi user mode.
On the console do:
# shutdown now (Note: without -r or -h) # return # exit
10.22. I tried to update my system to the latest -STABLE, but got -BETAx, -RC or -PRERELEASE! What is going on?
Short answer: it is just a name. RC stands for “Release Candidate”. It signifies that a release is imminent. In FreeBSD, -PRERELEASE is typically synonymous with the code freeze before a release. (For some releases, the -BETA label was used in the same way as -PRERELEASE.)
Long answer: FreeBSD derives its releases from one of two places. Major, dot-zero, releases, such as 4.0-RELEASE and 5.0-RELEASE, are branched from the head of the development stream, commonly referred to as -CURRENT. Minor releases, such as 4.1-RELEASE or 5.2-RELEASE, have been snapshots of the active -STABLE branch. Starting with 4.3-RELEASE, each release also now has its own branch which can be tracked by people requiring an extremely conservative rate of development (typically only security advisories).
When a release is about to be made, the branch from which it will be derived from has to undergo a certain process. Part of this process is a code freeze. When a code freeze is initiated, the name of the branch is changed to reflect that it is about to become a release. For example, if the branch used to be called 4.5-STABLE, its name will be changed to 4.6-PRERELEASE to signify the code freeze and signify that extra pre-release testing should be happening. Bug fixes can still be committed to be part of the release. When the source code is in shape for the release the name will be changed to 4.6-RC to signify that a release is about to be made from it. Once in the RC stage, only the most critical bugs found can be fixed. Once the release (4.6-RELEASE in this example) and release branch have been made, the branch will be renamed to 4.6-STABLE.
For more information on version numbers and the various CVS branches, refer to the Release Engineering article.
Short answer: You are probably at security level greater than 0. Reboot directly to single user mode to install the kernel.
Long answer: FreeBSD disallows changing system flags at security levels greater than 0. You can check your security level with the command:
# sysctl kern.securelevel
You cannot lower the security level; you have to boot to single mode to install the kernel, or change the security level in /etc/rc.conf then reboot. See the init(8) manual page for details on securelevel, and see /etc/defaults/rc.conf and the rc.conf(5) manual page for more information on rc.conf.
Short answer: You are probably at security level greater than 1. Reboot directly to single user mode to change the date.
Long answer: FreeBSD disallows changing the time by more that one second at security levels greater than 1. You can check your security level with the command:
# sysctl kern.securelevel
You cannot lower the security level; you have to boot to single mode to change the date, or change the security level in /etc/rc.conf then reboot. See the init(8) manual page for details on securelevel, and see /etc/defaults/rc.conf and the rc.conf(5) manual page for more information on rc.conf.
No, there is no memory leak, and it is not using 256 Mbytes of memory. For convenience, rpc.statd maps an obscene amount of memory into its address space. There is nothing terribly wrong with this from a technical standpoint; it just throws off things like top(1) and ps(1).
rpc.statd(8) maps its status file (resident on /var) into its address space; to save worrying about remapping it later when it needs to grow, it maps it with a generous size. This is very evident from the source code, where one can see that the length argument to mmap(2) is 0x10000000, or one sixteenth of the address space on an IA32, or exactly 256MB.
You are running at an elevated (i.e., greater than 0) securelevel. Lower the securelevel and try again. For more information, see the FAQ entry on securelevel and the init(8) manual page.
10.27. Why does SSH authentication through .shosts not work by default in recent versions of FreeBSD?
The reason why .shosts authentication does not work by default in more recent versions of FreeBSD is because ssh(1) is not installed suid root by default. To “fix” this, you can do one of the following:
As a permanent fix, set ENABLE_SUID_SSH to true in /etc/make.conf and rebuild ssh (or run make world).
As a temporary fix, change the mode on /usr/bin/ssh to 4555 by running chmod 4555 /usr/bin/ssh as root. Then add ENABLE_SUID_SSH= true to /etc/make.conf so the change takes effect the next time make world is run.
vnlru flushes and frees vnodes when the system hits
the kern.maxvnodes limit. This kernel thread sits mostly
idle, and only activates if you have a huge amount of RAM and are accessing tens of
thousands of tiny files.
Active: pages recently statistically used.
Inactive: pages recently statistically unused.
Cache: (most often) pages that have percolated from inactive to a status where they maintain their data, but can often be immediately reused (either with their old association, or reused with a new association.) There can be certain immediate transitions from active to cache state if the page is known to be clean (unmodified), but that transition is a matter of policy, depending upon the algorithm choice of the VM system maintainer.
Free: pages without data content, and can be immediately used in certain circumstances where cache pages might be ineligible. Free pages can be reused at interrupt or process state.
Wired: pages that are fixed into memory, usually for kernel purposes, but also sometimes for special use in processes.
Pages are most often written to disk (sort of a VM sync) when they are in the inactive state, but active pages can also be synced (but requires the availability of certain CPU features.) This depends upon the CPU tracking of the modified bit being available, and in certain situations there can be an advantage for a block of VM pages to be synced, whether they are active or inactive. In most common cases, it is best to think of the inactive queue to be a queue of relatively unused pages that might or might not be in the process of being written to disk. Cached pages are already synced, not mapped, but available for immediate process use with their old association or with a new association. Free pages are available at interrupt level, but cached or free pages can be used at process state for reuse. Cache pages are not adequately locked to be available at interrupt level.
There are some other flags (e.g., busy flag or busy count) that might modify some of the rules that I described.
There are a couple of kinds of “free memory”. One kind is the amount of memory immediately available without paging anything else out. That is approximately the size of cache queue + size of free queue (with a derating factor, depending upon system tuning.) Another kind of “free memory” is the total amount of VM space. That can be complex, but is dependent upon the amount of swap space and memory. Other kinds of “free memory” descriptions are also possible, but it is relatively useless to define these, but rather it is important to make sure that the paging rate is kept low, and to avoid running out of swap space.
/var/empty is a directory that the sshd(8) program uses when performing privilege separation. The /var/empty directory is empty, owned by root and has the schg flag set.
Although it is not recommended to delete this directory, to do so you will need to unset the schg flag first. See the chflags(1) manual page for more information (and bear in mind the answer to the question on unsetting the schg flag).
This, and other documents, can be downloaded from ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
For questions about FreeBSD, read the documentation before contacting <[email protected]>.
For questions about this documentation, e-mail <[email protected]>.