FreeBSDwiki - User contributions [en]

Apache, Configuring

2012-08-06T01:39:16Z

200.38.30.168: Remove spam about goodville from user DavidYoung.

The [[Apache]] webserver's main configuration file is the [[httpd.conf]] file, which, if you've installed apache via ports and left it at defaults, will be found in /usr/local/etc and basic management is done via [[apachectl]]. If you prefer a GUI method of configuring and managing apache, look to [[webmin]], but it is always advisable to know how to make the changes in the config file manually, since you may not be able to configure a specific setting or change via the [[webmin]] GUI.

==Testing your configuration==

When changing your config file, you may want to verify that the config file doesn't have any syntax problems:
apachectl configtest

Note that your config can be free of syntax errors and still broken -- in the same way you can use words correctly but say the wrong thing, being free of syntax errors doesn't mean your config is free of all errors. :)

==Advanced Config and Optimization==

If you've got a busy webserver, you'll soon find yourself looking at tweaking the Apache configuration to get more. As it is, most Apache installs are configured for testing / development vs production use.

==MPM==

By default, the httpd.conf has MPM (multi-processing modules) specific settings for all possible MPM choices. However, since this choice is made at compile-time, all but one of these MPM specific can be safely removed. The default (and usually the recommended) MPM is prefork.

Look for this section in your default httpd.conf:

##
## Server-Pool Size Regulation (MPM specific)
##

Read more about what an MPM is here: http://httpd.apache.org/docs/2.0/mpm.html.

===Prefork===

This is the default MPM and will work fine for most applications.

Default:
# prefork MPM
# StartServers: number of server processes to start
# MinSpareServers: minimum number of server processes which are kept spare
# MaxSpareServers: maximum number of server processes which are kept spare
# MaxClients: maximum number of server processes allowed to start
# MaxRequestsPerChild: maximum number of requests a server process serves
<IfModule prefork.c>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 150
MaxRequestsPerChild 0
</IfModule>

Tweaked:
StartServers 10
MinSpareServers 10
MaxSpareServers 20
MaxClients 256
MaxRequestsPerChild 15000

'''StartServers, MinSpareServers, MaxSpareServers'''
Creating a child process can be one of the most expensive in terms of CPU usage. Experiment with raising these values... as a start, you can probably safely double them and go from there. During traffic spikes, the server will have more available, idle child processes already created, which should help reduce load and keep the server busier serving content than spawning new servers when needed.

'''MaxClients'''
With a busy website you may start reaching the default MaxClients, in which case everyone else is locked out. This error will show up in your error logs. Please note that there is a hard limit of 256 for this directive. Raising it requires setting a compile-time option and reinstalling. Still, 256 is much heftier than 150, so this may work out fine.

'''MaxRequestsPerChild'''
Leaving this at 0 means a child never dies... once its created it will serve an unlimited number of requests until the main daemon kills it off during traffic lulls. Setting this to a high number has the benefit of periodically refreshing the pool of child processes and keeping memory leakage to a minimum.

===Worker===

In order to try out the worker MPM, you must re-install Apache2 with different MAKE_ARGS. For the brave, please see this page: [[Apache2 with the Worker MPM]].

==KeepAlives==

The KeepAlives directive is enabled by default; to quote from the Apache documentation:
The Keep-Alive extension to HTTP/1.0 and the persistent connection feature of
HTTP/1.1 provide long-lived HTTP sessions which allow multiple requests to be
sent over the same TCP connection. In some cases this has been shown to result
in an almost 50% speedup in latency times for HTML documents with many images.

Which is a good thing, if you want fast pages and have a strong server to handle it. If you're more concerned with availability than speed, or are running Apache on a less-than-stellar machine, you may get better performance (cpu/processor-wise, at least,) by turning KeepAlives off:

Default:
KeepAlives On

Tweaked:
KeepAlives Off

==Include directive==
'''Note:''' ''Do not confuse the '''''Include directive''''' with ''Option Includes'', or the ''INCLUDES filter''.

''httpd.conf'' is a large file, and it can be difficult to find things in it to maintain custom settings. The '''Include directive''' is very useful for maintaining custom configurations in a modular way. It allows inclusion of other configuration files, adding the directives contained in them to the server configuration.

For example, you may want to add virtual hosts, or temporarily grant browser-access to a directory, to others on your LAN, or similar custom configuration directives. You can put directives for any context into a separate file and save the file as (for example) /usr/local/etc/{apacheversion}/includes/{custom_directive}.conf. This is especially useful for configuration options that change relatively frequently. Your custom configuration will be added to the server by adding the following line to ''httpd.conf'' (e.g. for apache2):

Include etc/apache2/includes/custom_directive.conf

Multiple Include lines are permitted. You can include everything in the directory by specifying the directory rather than a single file, but much more preferrably since Apache 2.0.41, you can use wildcards:

# Include etc/apache2/includes/ # everything in the directory will be included
Include etc/apache2/includes/*.conf # wildcards recommended rather than the whole directory

The file path specified may be an absolute path or relative to the [http://httpd.apache.org/docs/trunk/mod/core.html#serverroot ServerRoot] directory (as above).

;Example: ('/usr/local/etc/apache2/includes/directories.conf')
Alias /samples /usr/home/storage/_Samples
<Directory "/usr/home/storage/_Samples">
Options Indexes
DirectoryIndex index.html index.php
AllowOverride None
Order allow,deny
Allow from all
</Directory>

[[Category: Ports and Packages]]
[[Category: Configuring FreeBSD]]

Apache

2012-08-06T01:38:59Z

200.38.30.168: Remove spam about goodville from user DavidYoung.

[[Apache]] is an (some would say ''the'') open source webserver; used more than any other webserver in the world. It is available for easy installation from FreeBSD's [[:Category:Ports and Packages|ports tree]] in several different flavors, including pre-configured versions with and without [[OpenSSL]], [[mod_php]], [[frontpage extensions]], and lots more.

Apache fits most purposes well, however when configured with PHP and/or mod_perl its memory requirements scale upwards dramatically, so for particularly high-volume applications a separate server for static content becomes very desirable. Apache itself is reasonably light when the aforementioned modules are not loaded, however [[thttpd]] is even lighter. A reverse proxy setup also solves the problem well.

See also:
[[Apache2_Installation]] - [[Apache Controlling]] - [[Installing_Apache_with_PHP]]

[[Category:Ports and Packages]]

.bashrc

2012-08-06T01:38:30Z

200.38.30.168: Undo revision 12926 by DavidYoung (talk)

.bashrc is a script located in a user's home directory which will be executed when the [[bash]] [[shell]] starts. an example .bashrc is below. note that this is a bashrc from a linux system which I commented out a bunch of stuff that isn't supported over ssh/terminal sessions.

dave@samizdata:~% more .bashrc
# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples

# If running interactively, then:
if [ "$PS1" ]; then

# don't put duplicate lines in the history. See bash(1) for more options
# export HISTCONTROL=ignoredups
# check the window size after each command and, if necessary,
# update the values of LINES and COLUMNS.
#shopt -s checkwinsize

# enable color support of ls and also add handy aliases
# if [ "$TERM" != "dumb" ]; then
# eval `dircolors -b`
# alias ls='ls --color=auto'
# alias dir='ls --color=auto --format=vertical'
# alias vdir='ls --color=auto --format=long'
# fi
# some more ls aliases
# alias ll='ls -l'
# alias la='ls -A'
# alias l='ls -CF'

# less pipes automagically
# eval `lesspipe`

# set a fancy prompt
PS1='\u@\h:\w% '

# If this is an xterm set the title to user@host:dir
case $TERM in
xterm*)
PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME}: ${PWD}\007"'
;;
*)
;;
esac

# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc).
#if [ -f /etc/bash_completion ]; then
# . /etc/bash_completion
#fi
fi

[[Category:Important Config Files]]

.cshrc

2012-08-06T01:38:04Z

200.38.30.168: Undo revision 12927 by DavidYoung (talk)

As you may be able to guess, this is the [[shell configuration file]] for the C-shell.

==Prompts==
Modifying your prompt can make your work experience more productive. Here are some common variables for customizing your C-Shell prompt:

* %/ - The current working directory shown as /home/user/
* %~ - The current working directory with your own home directory shown as "~" and other users shown as "~user"
* %m - The machine's hostname up until the first . (Ex: freebsd.yourdomain.com would show up as simply "freebsd")
* %n - Displays the username you are logged on as
* %M - The machine's full hostname (Ex: freebsd.yourdomain.com)
* %t - Shows the time in 12 hour format (Ex: 4:04pm)
* %T - Shows the time in 24 hour format (Ex: 16:04)
* %p - Shows the "precise" time of day in 12 hour format (Ex: 4:04:01)
* %P - Shows the "precise" time of day in 24 hour format (Ex: 16:04:01)

To experiment with various prompts, use the command '''set prompt'''. Here is an example:

% set prompt='[%t][%n@%m:%~]% '

Now your prompt looks like this:

[4:04pm][mixx941@freebsd:~]%

To make these changes permanent, you can add the "set prompt" line above into your .cshrc file. If you wish to make them global for all accounts, add that line into /etc/csh.cshrc

[[Category:Important Config Files]]

.htaccess

2012-08-06T01:35:49Z

200.38.30.168: Undo revision 12928 by DavidYoung (talk)

You can place a .htaccess file in a directory serviced by [[apache]] to override server default behaviors without needing to alter [[httpd.conf]] or even to restart Apache - assuming, of course, that the directory in question has been allowed override privileges for the things you want to do!

For example, assuming [[mod_rewrite]] is installed and available in Apache, you can do the following in the .htaccess file in the root of a site to redirect an insecure http request to the same site via secure https:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

Or if you want to block off a pesky spammer-ridden IP block from posting things to a blog or wiki, while still allowing people on that block to READ the blog or wiki or what have you:

AuthName "Anti-Spam Protection"
AuthType Basic
<Limit PUT POST>
order allow,deny
allow from all

# CHINANET telcom - 2006-03-02
deny from 212.0.0.0/8
deny from 216.0.0.0/8
deny from 218.0.0.0/8
deny from 221.0.0.0/8
deny from 61.144.0.0/14
</Limit>

Note that comments - prefaced by # signs - ARE allowed in .htaccess files. Use this to your advantage!

What if you want to require a password for a certain directory?

# require a username and password to get into this lightly secured area
AuthType Basic
# note: it's safest to keep the password file OUTSIDE the webroot!
AuthUserFile ../.htpasswd
AuthName "JRS Systems Personnel Only"
require valid-user
satisfy any

Of course, this requires you to actually have a [[.htpasswd]] file in the appropriate location - you can use the [[htpasswd]] utility to create one for you.

[[Category:Important Config Files]]

.profile

2012-08-06T01:34:58Z

200.38.30.168: Undo revision 12929 by DavidYoung (talk)

the configuration file (located in your home directory) that tells your shell how to behave; .profile will work for almost all shells. For more advanced shells (i.e., anything that's not the [[Bourne Shell]],) it's usually set to redirect to the proper shell's .profile.

see also .[[shell]]_profile (e.g., .bash_profile)

an example of .bash_profile:
dave@samizdata:~% more .bash_profile
# ~/.bash_profile: executed by bash(1) for login shells.
# see /usr/share/doc/bash/examples/startup-files for examples.
# the files are located in the bash-doc package.
# the default umask is set in /etc/login.defs
#umask 022
# the rest of this file is commented out.
# include .bashrc if it exists
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
# set PATH so it includes user's private bin if it exists
if [ -d ~/bin ] ; then
PATH=~/bin:"${PATH}"
fi
# do the same with MANPATH
#if [ -d ~/man ]; then
# MANPATH=~/man:"${MANPATH}"
# export MANPATH
#fi

[[Category:Important Config Files]]

/etc/resolv.conf

2012-08-06T01:34:33Z

200.38.30.168: Undo revision 12934 by DavidYoung (talk)

see resolv.conf

/usr/local/etc/rc.d

2012-08-06T01:33:59Z

200.38.30.168: Remove spam about goodville from user DavidYoung.

ACPI, enabling

2012-08-06T01:33:00Z

200.38.30.168: Remove spam about goodville from user DavidYoung.

== Making ACPI work in FreeBSD 5.x ==

Many manufacturers' motherboards have dodgy implementations of ACPI that are based on "works with Windows" as opposed to "adheres to the ACPI standard." As usual, microshit only pays attention to the parts of the ACPI standard they care about and ignore the rest, so FreeBSD's standards-based implementation can have some issues with some motherboards, particularly non-SMP motherboards, that were designed around Windows rather than being designed standards-compliant. Many of these boards can be made to work with ACPI, however, by creating a custom kernel with the following options:

# Do NOT make an SMP kernel
# options SMP # Symmetric MultiProcessor Kernel
nodevice apic
nodevice smp

Note that in addition to adding "nodevice apic" and "nodevice smp", "options SMP" has been commented out. The GENERIC kernel in 5.2.1 has SMP on by default, and many non-SMP motherboards do not correctly identify themselves as such under ACPI - leaving you with the options of either disabling ACPI or disabling SMP and APIC. ACPI gives you lots of good stuff like power control and monitoring and more fine-grained hardware controls, so you're really better off building yourself a custom non-SMP kernel and booting with ACPI on.

See [[Custom Kernels]] if you need more information on how to find, edit, build, and install a custom kernel in general.
[[Category:Common Tasks]]

ATTRIB

2012-08-06T01:32:21Z

200.38.30.168: Remove spam about goodville from user DavidYoung.

'''ATTRIB''' is the DOS command to get or set the ''read-only'', ''archive'', ''system'', and ''hidden'' attributes of a file or directory. Under FreeBSD and other unixlike OSes, the equivalent command is [[chmod]]. (See also: [[chown]])

[[Category:Windows Equivalents]]

AccessPoint

2012-08-06T00:22:57Z

200.38.30.168: Remove spam about goodville from user DavidYoung.

==Introduction==
FreeBSD is very well suited for use as a wifi access point as it has 'master mode' support for a variety of wifi network cards, out of the box. Some of these include ralink and Atheros cards.

There are many difficulties setting up a wireless network access point on linux. Some of the problems(with non madwifi cards) include:
*You must use a kernel that is yet-to-be released (2.6.26-rc4).
*You must patch the kernel. [http://johannes.sipsolutions.net/patches/kernel/all/LATEST/006-allow-ap-vlan-modes.patch Download Patch]
*You must compile a recent libnl(I used libnl-1.1-r1, on Gentoo) against the custom kernel.
*On Gentoo you need to copy nl80211.h from your kenrel directory to /usr/include/linux
*Finally, you need to compile a git version of hostapd...

All of the above steps must be completed for maximum support of various wireless network cards. Most other sets are fairly similar to those on FreeBSD.

<i>On this Howto we will assume that your modem gives you a dhcp address,see [[AccessPoint using pppoe]] if you need to setup PPPOE</i>

==The hardware==
For my setup, and the instructions included here, I used:
*2 Realtech PCI 10/100 cards, on FreeBSD. These cards are recognized as rl0 and rl1. (Perhaps there is the possibility to use interfaces aliasing, but as i had 2 cards...)
*1 Ralink rt2500 PCI card, on FreeBSD. This card is recognized as ral0.

== Installation and Configuration==
* Install FreeBSD as usual. This example uses FreeBSD 7.0.
* Enable ssh logins during the installation, or add the following line to your /etc/rc.conf:
<pre>sshd_enable="YES"</pre>
* If you have a DHCP-enabled modem, you can add the following to your /etc/rc.conf:
<pre>ifconfig_rl0="DHCP"</pre>
<i>Note, make certain you replace rl0 with your wired network interface name.</i>

===Wireless===
To configure the wireless card, the following commands need to be executed:
<pre>ifconfig ral0 inet 192.168.1.1 netmask 255.255.255.0 ssid freebsdap mediaopt hostap channel 4</pre>
Note that, in the [http://www.freebsd.org/handbook FreeBSD Handbook], inet is placed incorrectly. Also, make certain to include a channel number. Without it, I was unable to get this working.

Next, try to associate to the new AP from a client. If something goes wrong (i.e. ping doesn't work), look to dmesg for debugging output. Specifically, look for association messages.

Finally, if you can see the wireless network, and can ping it, simply add the following to /etc/rc.conf:
<pre>ifconfig_ral0="inet 192.168.1.1 netmask 255.255.255.0 ssid freebsdap mediaopt hostap channel 4"</pre>

==== Useful Association Commands ====

Under GNU/Linux type as root(remplacing wlan0 by your wifi card interface name):
<pre>ifconfig wlan0 up
iwlist wlan0 scan
iwconfig wlan0 essid "freebsdap"
ifconfig wlan0 192.168.1.100 netmask 255.255.255.0
ping 192.168.1.1</pre>
Under FreeBSD type as root(remplacing ral0 by your wifi card interface name):
<pre>ifconfig ral0 up
ifconfig ral0 list scan
ifconfig ral0 inet 192.168.1.100 netmask 255.255.255.0 ssid freebsdap
ping 192.168.1.1</pre>

===DNS and DHCP===
Once the wireless AP is working, we can install DNS and DHCP servers. For simplicity, we will use dnsmasq. As root, execute the following command:
<pre>cd /usr/ports/dns/dnsmasq && make config && make install</pre>

On the configuration menu, deselect the followingn options:
* ipv6
* dbus

Once installed, we need to configure dnsmasq:

Edit /usr/local/etc/dnsmasq.conf with your favorite editor and add the following:
<pre># filter what we send upstream
domain-needed
bogus-priv
filterwin2k
localise-queries

# allow /etc/hosts and dhcp lookups via *.lan
local=/lan/
domain=workgroup
expand-hosts
#resolv-file=/tmp/resolv.conf.auto

dhcp-authoritative
#dhcp-leasefile=/tmp/dhcp.leases

# use /etc/ethers for static hosts; same format as --dhcp-host
# <hwaddr> <ipaddr>
read-ethers

# other useful options:
# default route(s):
dhcp-option=3,192.168.1.1
# dns server(s):
dhcp-option=6,192.168.1.1

dhcp-range=192.168.1.100,192.168.1.255,255.255.255.0,12h</pre>

The option, read-ethers, permits you to assign statics IPs to certain MAC addresses. Edit /etc/ethers with entries as follows:
<pre>00:14:85:11:EF:02 192.168.1.106</pre>

In order to give a DNS name to this entry, edit /etc/hosts and add an entry like this:
<pre>192.168.1.106 Ralink</pre>

To start your dnsmasq server at boot, add the following to /etc/rc.conf:
<pre>dnsmasq_enable="YES"</pre>

You can now test the wifi connection with any graphical tool (like NetworkManager in GNU/linux or even test it with a windows computer) you can even try to ping a website... but you will only get his ip and no response...that's because we didn't set up the NAT yet...

==Nat and firewall==
in order to set the nat we will add this to /etc/rc.conf:(remplacing ral0 by your wired card(that is connected to the internet) interface name)::
gateway_enable="YES"
firewall_enable="YES"
firewall_type="OPEN"
natd_enable="YES"
natd_interface="rl0"
natd_flags=""
if you wish to redirect ports add this to natd_flags="" in /etc/rc.conf:
-redirect_port tcp 192.168.0.6:80 80

now normally the access point should work...

==OpenVPN==
===Introduction===
now that we have wireless we could choose between theses choices:
*having a full open wireless(not great for security)
*having a wpa wireless(not compatible with all drivers,devices doesn't always work),no guests...
*having an open wireless while encrypting the data sent to to wireless access point...yes that is possible...with the help of openvpn

i chose the third possibility.
===installation===
here the commands to run in order to install openvpn:
cd /usr/ports/security/openvpn
make
make install
===configuration===
====EasyRsa====
install bash:
cd /usr/ports/shells/bash
make
make install
ln -s /usr/local/bin/bash /bin/bash
run theses commands:
cp -r /usr/local/share/doc/openvpn/easy-rsa/2.0/ /root/easy-rsa-2.0
here we will copy it in order not to have our keys erased by an update...
then we will need bash run:
/bin/bash
cd /root/easy-rsa-2.0
then we will make the certificates:
modify the vars script in order to suit your needs,then run:
source ./vars
./clean all
./build-ca ca
then we will build the server key:
./build-key-server server
then we will build the clients key:
./build-key client1
./build-key client2
then we genreate diffie helman parameters:
./build-dh

in order to build a new client just do:
source ./vars
./build-key client2

then copy the keys at the keys location:
cp -r keys /usr/local/etc/openvpn/keys
alternatively you can do the following:
mkdir /usr/local/etc/openvpn/keys/
cd /root/easy-rsa-2.0/keys
cp ca.crt /usr/local/etc/openvpn/keys/ca.crt
cp server.crt /usr/local/etc/openvpn/keys/server.crt
cp server.key /usr/local/etc/openvpn/keys/server.key
cp dh1024.pem /usr/local/etc/openvpn/keys/dh1024.pem

====OpenVpn configuration====
We will first install all in test-mode that is to say not runnning ... \n

Administrator

2012-08-06T00:22:16Z

200.38.30.168: Remove spam about goodville from user DavidYoung.

The Administrator is a user account typically found on microshit Windows platforms based on Windows NT, including desktop operating systems Windows 2000, XP and Vista and the server platforms NT 4.0 Server, Windows Server 2000 and Windows 2003 Server (and variants). It is the "super-user" account typically used by IT systems personnel to maintain these operating systems.

On FreeBSD and other UNIX and Unix-alike platforms (including Linux) the equivalent to the Administrator account is the [[root]] account. This is the "super-user" of Unix and is similarly used by IT systems personnel.

The two super-user accounts are similar in that they exist as part of the default installation and give top-level access to the operating system.

On microshit platforms regular user accounts can be given Administrator privileges where-as on Unix platforms a regular user must be given rights to issue the [[su]] command to gain a root shell, or rights to use [[sudo]] to execute a specific command or script as root.

== Important Warning ==

There are absolutely no system processes more privileged than root and there is no restriction on what root can do on a FreeBSD system. If you type '''rm -rf /*''' as root, all files on your system (including system files) will be deleted without even asking for confirmation. (Don't do this on a system you weren't about to format anyway!)

Remember: ''"With great power comes great responsibility."''

== Notes ==

On unix systems, the [[init]] process is the "root" process and all other processes can be considered "child" processes of it. As root, you can change the [[init]] status of your system.

[[Category:Windows Equivalents]]

Alias

2012-08-06T00:21:45Z

200.38.30.168: Remove spam about goodville from user DavidYoung.

The '''alias''' command: [[Alias (command)]]

Adding an '''alias''' IP address to a NIC: [[IP addresses, multiple]]

ARP

2012-08-06T00:21:18Z

200.38.30.168: Remove spam about goodville from user DavidYoung.

ARP (Address Resolution Protocol) is used on a [[LAN]] to map [[IP]] addresses to physical [[MAC]] addresses.

Technically, this is not specific to FreeBSD, but if you're using your FreeBSD box as a gateway, this is something that you'll need know (also how to clear the ARP cache on your switch, if you're on a switched network).

[[Category: FreeBSD Terminology]]

Alias (command)

2012-08-06T00:20:30Z

200.38.30.168: Remove spam about goodville from user DavidYoung.

The [[alias]] command is used to create '''aliases''', and to get a list of aliased commands.

==Aliases creation==

The syntax is shell dependent:

'''B-Shell''' ([[sh]], [[bash]]) and '''Z-Shell''' ([[zsh]]) :
alias l=ls
alias la='ls -A'

'''C-Shell''' ([[csh]], [[tcsh]]) :
alias l ls
alias la 'ls -A'

==Special functions==

Some shells provide additional features, such as the '''-g''' argument of [[zsh]]'s alias [[built-in]] command. This allow creation of ''global aliases'' :
'''> alias a=aaa'''
'''> alias -g b=bbb'''
'''> echo a b'''
a bbb
This can be very useful :
'''> alias -g ...='../..''''
'''> pwd'''
/foo/bar/misc
'''> cd ...'''
'''> pwd'''
/foo

For more information on the specific options of your shell, check its man page.

==Aliases consultation==

You can use this to get a list of existing '''aliases''':
'''> alias'''
...=../..
....=../../..
.....=../../../..
......=../../../../..
.......=../../../../../..
clean='rm -f `find . -name "*~" -o -name ".*~" -o -name ".*.core" -o -name "*.core" -o -name "#*#" -o -name "a.out"`
close='cdcontrol -f /dev/cd0 close'
eject='cdcontrol -f /dev/cd0 eject'
fr='export LANG=fr_FR.ISO8859-15'
la='ls -a'
ll='ls -Al'
ls='ls -FG'
'''> alias ls'''
ls='ls -FG'

See also: [[unalias]], [[which]]

[[Category : System Commands]]

Amarok

2012-08-06T00:20:00Z

200.38.30.168: Remove spam about goodville from user DavidYoung.

Amarok is a media player for unix-like systems. Some of the features are: Podcasting, wikipedia built-in for artist lookup, library of all your music, save and restore playlists, connect to ipod or other mp3 devices and sync content, burn your playlist from amarok (calls [[k3b]])

Installable via ports or by packages:
pkg_add -r amarok

[[Category:Ports and Packages]]

Apache, Controlling

2012-08-06T00:18:36Z

200.38.30.168: Remove spam about goodville from user DavidYoung.

Want to see if it works? If you just got done installing Apache, first of all, issue a '''rehash''' command to reindex your system's PATH. Then let's get started:

ph34r# '''apachectl start'''
/usr/local/sbin/apachectl start: httpd started

Don't take its word for it, though - sometimes [[apachectl]] lies through its teeth. Let's make sure we really do have some '''httpd''' processes running:

ph34r# '''ps ax | grep http'''
18564 ?? SsJ 0:00.74 /usr/local/sbin/httpd
18566 ?? IJ 0:02.71 /usr/local/sbin/httpd
18567 ?? IJ 0:01.12 /usr/local/sbin/httpd
18568 ?? IJ 0:00.64 /usr/local/sbin/httpd
18569 ?? IJ 0:02.10 /usr/local/sbin/httpd
18570 ?? IJ 0:06.16 /usr/local/sbin/httpd
18612 ?? IJ 0:03.00 /usr/local/sbin/httpd
18621 ?? IJ 0:03.94 /usr/local/sbin/httpd
18639 ?? IJ 0:05.96 /usr/local/sbin/httpd
18644 ?? IJ 0:01.60 /usr/local/sbin/httpd
18645 ?? IJ 0:02.05 /usr/local/sbin/httpd

Okay, good, looks kosher. You're probably going to want Apache to run automatically whenever the server boots, though, right? Well, there are two ways to go about doing that. One way is to edit [[ /etc/rc.conf]] and set some variables that will then cause the default apache.sh / apache2.sh startup script that the port placed in [[ /usr/local/etc/rc.d]] to actually do something when the machine starts... but we're not going to talk about that way, because I personally despise forcing the administrator to maintain two files where one would do. So instead, we're just going to write our own script for [[ /usr/local/etc/rc.d]] that will start Apache all on its lonesome, regardless of what is or isn't in [[ /etc/rc.conf]]. So make yourself a new script and name it '''/usr/local/etc/rc.d/apache.sh''', and make it look like this:

#!/bin/sh

case "$1" in
start)
/usr/local/sbin/apachectl start > /dev/null && echo -n ' apache'
;;
stop)
/usr/local/sbin/apachectl stop > /dev/null && echo -n ' apache'
;;
*)
echo "Usage: `basename $0` {start|stop}" >&2
;;
esac

exit 0

Now you'll want to make sure that your new script 1. can get executed when the system starts, and 2. won't get clobbered the next time you upgrade Apache from the ports tree, so make it executable but NOT writeable:

ph34r# '''chmod 555 /usr/local/etc/rc.d/apache.sh'''

There you go - now that you've got a handle on starting and stopping Apache, move on to the basics of [[Configuring Apache]].

[[Category:Common Tasks]]

Apache, Digest Authentication

2012-08-06T00:18:05Z

200.38.30.168: Remove spam about goodville from user DavidYoung.

==Overview==
Traditionally, [[apache]] has used Basic authentication as a way to implement simple password protection on locations and directories. This is fine so far as it goes, but unfortunately while the .htpasswd file on the other end is encrypted, when a user authenticates the username and password are sent in cleartext. Apache also supports Digest authentication, which works almost identically, but does simple encryption of the ''transmitted'' username and password as well as the stored copies on the server.

Before you can use AuthDigest, you'll need to make sure the '''mod_auth_digest''' module is loaded in your Apache server. (It will be by default, if you have built Apache from ports.) The line enabling it in /usr/local/etc/apache22/httpd.conf looks like this:

LoadModule auth_digest_module libexec/apache22/mod_auth_digest.so

==Directives==
Once you've made sure your installation of Apache allows Digest authentication, you'll need to configure it for a Directory or a Location, which can be done in a .htaccess file in the directory to be protected (if AllowOverride Auth is set for that site), or in the Apache configs themselves. The configuration for Digest authentication looks very much like that for Basic authentication:

<Location />
AuthName 'Private'

AuthType Digest
AuthDigestProvider file
AuthDigestDomain /
AuthUserFile /data/www/sitename.tld/.htdigest

Require valid-user
</Location>

In this example, an entire website is protected with Digest authentication. Note the AuthDigestDomain directive; it should ''always'' be specified; otherwise the client will send the Authorization header for every request sent to the server. (In fact, in this example it wouldn't matter too much because the entire site WILL require the Authorization header - but it's a good habit to get into, particularly since you will usually only be protecting a certain part of a site.)

Also note that, unlike Basic authentication, the AuthName directive in a Digest-protected site serves as more than just "the text that pops up in a dialog box" when a user visits the protected area. With Digest authentication, the "Realm" specified by AuthName is a mandatory part of the user information in the ''.htdigest'' file and should match with the realm string specified in ''.htdigest''. Presumably, this is so that you can use a single .htdigest file with multiple sites even if the sites have overlap in usernames. That's probably a bad idea in most cases, though.

==Creating .htdigest Files==
The other side of Digest authentication is creating the .htdigest file; for that you will use the '''htdigest''' command, which functions much like the '''htpasswd''' command. As mentioned above, however, you MUST specify a Realm when creating a user with '''htdigest''', and the Realm MUST match the text in the AuthName directive. In this example, we'll create a .htdigest file to go along with the Digest directives shown above:

me@box:~$ '''htdigest -c /data/www/sitename.tld/.htdigest 'Private' 'username' '''
Adding password for username in realm Private.
New password:
Re-type new password:
me@box:~$ '''cat /data/www/sitename.tld/.htdigest''
username:Private:793b5dd9aceaa4314b3aa350b55d6bd3

As you can see, the .htdigest file contains the Realm as well as the username and a hashed copy of the password. Also note that we used single quotes to encapsulate username and realm in the htdigest command - that's not strictly necessary, but it's good practice; many sites want to use sentences rather than single words in the Authentication dialog box, which means you need to be able to use them in the htdigest command as well. And no, you can't just go into the .htdigest file and edit the Realm name afterwards - the hash is actually a hash of '''username:realm:password''' all together, so it won't work if you change the realm after it's created. (See http://httpd.apache.org/docs/2.2/misc/password_encryptions.html for details)

Now that you've got your .htdigest file created and your AuthDigest directives written, you'll need to restart Apache to put them in place (unless you used a .htaccess file to implement them instead of doing it in the Apache conf files).

==Problems Restarting Apache==
There's a nasty, unexpected SNAFU that you may run into the first time you restart Apache after enabling Digest authentication:

box# '''apachectl restart'''
box#

It ''looks'' like everything restarted just fine... but when you go to browse ''any'' site on the server, you may get timeouts, and when you check to see if Apache's running, you may see only a single hung process doing nothing, instead of the usual 5 or 10 processes:

box# '''ps waux | grep httpd'''
root 2279 0.0 1.3 26904 13876 ?? Ss 2:44PM 0:08.13 /usr/local/sbin/httpd -k start

What's happening? Well, Digest authentication uses /dev/random pretty heavily, and you may not have enough randomness available on the system yet. If this is the case, then Apache will hang and do absolutely nothing until enough randomness accumulates for it to get the data it's looking for from the /dev/random device. (This may sound odd, but no, I am not kidding here.) If this happens to you, there's an easy workaround - ''generate'' some randomness by using the [[du]] command to thrash the heck out of your hard drives.

box# '''du -hs /data'''
39G /data
box# '''ps waux | grep httpd'''
www 15959 2.3 1.9 32528 19796 ?? S 2:51PM 0:00.47 /usr/local/sbin/httpd -k start
root 2279 0.0 1.3 26904 13876 ?? Ss 2:44PM 0:38.52 /usr/local/sbin/httpd -k start
www 15958 0.0 1.9 32532 19808 ?? I 2:51PM 0:00.47 /usr/local/sbin/httpd -k start
www 15960 0.0 1.3 26904 13892 ?? I 2:51PM 0:00.00 /usr/local/sbin/httpd -k start
www 15961 0.0 1.3 26904 13892 ?? I 2:51PM 0:00.00 /usr/local/sbin/httpd -k start
www 15962 0.0 1.3 26904 13892 ?? I 2:51PM 0:00.00 /usr/local/sbin/httpd -k start
www 15969 0.0 1.3 26904 13892 ?? I 2:52PM 0:00.00 /usr/local/sbin/httpd -k start
root 15983 0.0 0.0 348 212 p0 R+ 2:53PM 0:00.00 grep http

There we go - ''now'' we see all of our Apache child processes running, and when we go back to check the sites on this server, we'll find that they're running just fine as well.

[[Category:Common Tasks]][[Category:FreeBSD for Servers]][[Category:Apache]]

BIND, dynamic DNS, failover A records

2012-08-06T00:17:05Z

200.38.30.168: Remove spam about goodville from user DavidYoung.

== The problem: inexpensive but unreliable ISPs ==
If you've got a multi-homed network with multiple IP addresses from different ISPs, but you aren't a big enough organization to convince your ISPs to build [[BGP]] routes to connect to each other at your network, you will probably find it really handy to have a single DNS record that will automatically choose the best way to get to your network from the outside world.

In this example, "BSDcompany" runs a small office network ('''office.bsdcompany.com''') and a server in a colocated network facility ('''coloserver.bsdcompany.com'''). Frequently, they need to access network resources inside the office from the internet. Since neither of the two ISPs available at BSDcompany's office are particularly reliable, BSDcompany has a cable modem from one of them, a DSL modem from the other, and a dual-WAN router. Both the cable and the DSL use dynamic IP addresses, and the company already has a server in the office doing [[BIND (dynamic DNS)|dynamic DNS updates]] to '''cable-ip.office.bsdcompany.com''' and '''dsl-ip.office.bsdcompany.com'''.

BSDcompany's dual-WAN router provides load balancing and automatic failover redundancy for internet access from within the office. But BSDcompany wants similar redundancy and balancing from the ''outside'' coming ''in'' as well. So instead of randomly trying cable-ip.office.bsdcompany.com and dsl-ip.office.bsdcompany.com to see which (if either) is working at any particular time, they just want to be able to use a single name all the time and have it automatically take them to whichever ISP is up and/or faster at the moment.

== The solution: ddns-failover.pl (another freebsdwiki.net original) ==
BSDcompany decides to set up a [[cron]] job on their colo server to check the status and latency of each of their office WAN IPs. That script will then automatically update a third A record, '''office.bsdcompany.com''', with whichever is currently the quicker of the two office WANs to respond - and if both WANs are down, it will delete the record entirely until one or the other of them comes back up.

(Like the '''set-ddns.pl''' script in the [[BIND (dynamic DNS)|previous dynamic DNS article]], the variables '''ddns-failover.pl''' in UPPERCASE are things you should set to match your own situation, while the ones in lower or mixed case are generally things you shouldn't need to mess with.)

<nowiki>#!/usr/bin/perl

# ddns-failover.pl
#
# Copyright (c) 05-20-2006, JRS System Solutions
# All rights reserved under standard BSD license
# details: http://www.opensource.org/licenses/bsd-license.php
#
# Check each of two public IPs for the same multi-homed host,
# and set a dynamic DNS A record to point to the lower latency
# of the two. If both routes are down, delete the hostname
# entirely until one or both IPs come back up.

$WANDNS1 = 'cable-ip.office.bsdcompany.com';
$WANDNS2 = 'dsl-ip.office.bsdcompany.com';
$HOSTNAME = 'office.bsdcompany.com';
$NAMESERVER = 'coloserver.bsdcompany.com';
$KEYFILE = 'Koffice.bsdcompany.com.+157+15661.private';
$KEYDIR = '/usr/home/ddns';
$TTL = '10';

@wan1 = split(/\n/,`/sbin/ping -qc 1 -t 1 $WANDNS1`);
@wan2 = split(/\n/,`/sbin/ping -qc 1 -t 1 $WANDNS2`);

$wan1[0] =~ /$(\d*?\.\d*?\.\d*?\.\d*?)$/;
$wan1_ip = $1;
if ($wan1_ip == '') { $wan1_ip = 'NO HOST FOUND'; }
$wan2[0] =~ /$(\d*?\.\d*?\.\d*?\.\d*?)$/;
$wan2_ip = $1;
if ($wan2_ip == '') { $wan2_ip = 'NO HOST FOUND'; }

$wan1[3] =~ /(\d*?) packets received/;
$wan1_rcvd = $1;
$wan2[3] =~ /(\d*?) packets received/;
$wan2_rcvd = $1;

$wan1[4] =~ /\/(\d*?\.\d*?)\//;
$wan1_time = $1;
$wan2[4] =~ /\/(\d*?\.\d*?)\//;
$wan2_time = $1;

if ($wan1_rcvd != 1 && $wan2_rcvd == 1) {
print "WAN1 [$wan1_ip]: NO RESPONSE\nWAN2 [$wan2_ip]: $wan2_time" . "ms\nSET $HOSTNAME: WAN2\n";
$dnsip=$wan2_ip;
} elsif ($wan1_rcvd == 1 && $wan2_rcvd != 1) {
print "WAN1 [$wan1_ip]: $wan1_time" . "ms\nWAN2 [$wan2_ip]: NO RESPONSE\nSET $HOSTNAME: WAN1\n";
$dnsip=$wan1_ip;
} elsif ($wan1_rcvd != 1 && $wan2_rcvd !=1) {
print "WAN1 [$wan1_ip]: NO RESPONSE\nWAN2 [$wan2_ip]: NO RESPONSE\nDELETE $HOSTNAME\n";
$dnsip='NO';
} elsif ($wan1_time <= $wan2_time) {
print "WAN1 [$wan1_ip]: $wan1_time" . "ms\nWAN2 [$wan2_ip]: $wan2_time" . "ms\nSET $HOSTNAME: WAN1\n";
$dnsip=$wan1_ip;
} else {
print "WAN1 [$wan1_ip]: $wan1_time" . "ms\nWAN2 [$wan2_ip]: $wan2_time" . "ms\nSET $HOSTNAME: WAN2\n";
$dnsip=$wan2_ip;
}

chdir ($KEYDIR);
open (NSUPDATE, "| /usr/sbin/nsupdate -k $KEYFILE");
print NSUPDATE "server $NAMESERVER\n";
print NSUPDATE "update delete $HOSTNAME A\n";
if ($dnsip ne 'NO') {
print NSUPDATE "update add $HOSTNAME $TTL A $dnsip\n";
}
# print NSUPDATE "show\n";
print NSUPDATE "send\n";
close (NSUPDATE);</nowiki>

== Setting up permissions ==
To minimize security risks, the gurus at BSDcompany create a new user named "ddns", put this script and the copies of the key files for the zone (which they already had, when they [[BIND (dynamic DNS)|set up their dynamic DNS]] earlier) in the "ddns" user's home directory, and make sure to set the permissions on everything as restrictively as possible before setting up the [[cron]] job to actually run it.

coloserver# '''pw useradd ddns -s /sbin/nologin -d /usr/home/ddns'''
coloserver# '''mkdir /home/ddns'''
coloserver# '''cp /etc/namedb/zones/keys/Koffice.bsdcompany.com.+157+15661.private .'''
coloserver# '''cp /etc/namedb/zones/keys/Koffice.bsdcompany.com.+157+15661.key .'''
coloserver# '''chmod 400 Koffice.bsdcompany.com.+157+15661.*'''
coloserver# '''chmod 500 ddns-failover.pl'''
coloserver# '''ls -l'''
-r-------- 1 ddns wheel 130 May 20 12:22 Kph34r.tehinterweb.net.+157+23266.key
-r-------- 1 ddns wheel 145 May 20 13:17 Kph34r.tehinterweb.net.+157+23266.private
-r-x------ 1 ddns wheel 3108 May 23 01:27 ddns-failover.pl
coloserver# '''su ddns''
This account is currently not available.

Excellent: the '''ddns''' account is present but cannot be interactively logged into, the key files are readable (but not writeable or executable) only to it, and the script is executable (but not writeable) only to it. Now that the permissions are correct, it's time to do a test run - we'll run the script manually (using [[sudo]] to do so as the user '''ddns''', just like the [[cron]] job will) before we set it up to run automatically.

== Testing the script manually ==
coloserver# '''sudo -u ddns /usr/bin/perl /usr/home/ddns/ddns-failover.pl'''
WAN1 [128.32.64.5]: 94.302ms
WAN2 [144.69.42.18]: 85.341ms
SET office.bsdcompany.com: WAN2
coloserver# '''ping -qc 1 office.bsdcompany.com'''
PING office.bsdcompany.com (144.69.42.18): 56 data bytes

--- office.bsdcompany.com ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 85.038/85.038/85.038/0.000 ms

Perfect! Now, the BSDcompany folks force an apparent fail condition on WAN2 to make sure it ... \n

BIND, managing

2012-08-06T00:16:19Z

200.38.30.168: Remove spam about goodville from user DavidYoung.

By far the easiest way to manage BIND is via [[webmin]], which is all GUI click and drop-down menus (see image below). But you should at the very least know how to manage it via command line for systems that you cannot set up [[webmin]] on for whatever reason or for those times when webmin fails.

To add records to a zone, you'll need to find that zone's file, edit it to include the record, '''increase your SOA serial number''' (1st parameter on IN SOA line, commonly with comment "; Serial") and reload your server with
rndc reload

If your server is a slave and you want it to retransfer the records from the master:
rndc retransfer

To check the status of your server:
rndc status

For example:

number of zones: 1077
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
recursive clients: 1/0/1000
tcp clients: 0/100
server is up and running

To stop your server:
rndc stop

To flush the DNS cache:
rndc flush

BIND can be a pain to manage properly, and not without reason there are thousands of pages on how to do it written.

* [[http://www.bind9.net/manuals BIND9.net Manuals]]
* bind-users FAQ
* [[http://www.reedmedia.net/books/bind-dns BIND 9 DNS Administration Reference Book]]
* [[http://www.netwidget.net/books/apress/dns/ Pro DNS and BIND]]

And here's a screenshot of Webmin's "Bind 9 Dynamic Server" module (which you'll have to install separately from the webmin.com site; the basic webmin BIND module doesn't do views very well and was designed for BIND 8):

[[Image: bind9webmin.PNG]]

== See also: ==

[[BIND]]

[[BIND (installing)]]

[[BIND (configuring)]]

[[BIND (securing)]]

[[Category:Configuring FreeBSD]]
[[Category:Ports and Packages]]
[[Category:Common Tasks]]
[[Category:DNS]]

Background processes

2012-08-06T00:15:10Z

200.38.30.168: Remove spam about goodville from user DavidYoung.

See [[daemons]]

[[Category : Windows Equivalents]]

BIND, securing

2012-08-06T00:14:51Z

200.38.30.168: Remove spam about goodville from user DavidYoung.

==Your DNS network design==
Ideally, the strongest layout consists of '''at least''' two DNS servers on two wholly separate networks -- separate physically and logically (different locations, different IP nets.) At least two, because really you'll probably want three -- two that people know about and one that people don't know about: your hidden master DNS server. So: make two slave DNS servers, point them to your authoritative nameserver, which for the sake of security should only allow updates TO your slaves and connections FROM your admin's IP addresses and the slave servers. If you can, make it a non-routeable address (10.0.0.0/8, 192.168/16, etc) that your slaves reach either directly or through a NAT'd firewall.

==Do Not Pass Go, Do Not Collect 200$, Go Directly to Jail==
Setting your DNS server inside a jail means that you're going to have a bit of a pain on the initial setup and install but you'll be that much more secure if your DNS server '''does''' get hacked. By placing just what it needs to run and nothing else in the jail, anyone that gets in will have a harder time doing anything with your server or to your network; no compilers means no binaries can be built on your system itself to give you a trojan: your would-be attackers would have to build the binaries somewhere else and copy them over and hope they work on your system. If you've got backups of your DNS data -- and you should, the slaves would essentially function as backups -- then even the dreaded '''rm -rf /''' inside your jail shouldn't be fatal: promote your slave to master for all your zones, '''rm -rf''' your jail directory and re-create it, make it a slave and copy your data over again by [[HUP]]'ing your server and you're good to go (you'll probably want to find out how they got in to do Bad Things so that it doesn't happen again, though).

==Don't run as root==
Make a dns account to run your nameserver from; block it from accessing the net over anything but UDP/TCP ports 53 (using [[ACL]]s or a firewall etc).

==Use Views==
Views are a feature of BIND 9, essentially it boils down to keeping two sets of data for a given zone and setting an [[ACL]] for each of them. So that internally, your network has a DNS server that has records for every machine you want -- every single networked printer, router, switch, workstation and server, if you like -- and externally, only what needs to be accessible from the world has a record.

==Don't rely on just network security or just host security: use both==
Well, your network has a [[bastion host]] and it's protecting the whole network, including your DNS server, so why worry, right? Right. Maybe. Or Maybe Wrong. Maybe really wrong. In any case, better safe than sorry: recompile your FreeBSD kernel and include [[ipfw]] in it and set your firewall rules to just what you need: UDP/TCP 53 (DNS), TCP 22 (SSH), and possibly your [[webmin]] management port for your networks.

==Poison is bad==
DNS cache poisoning is one of many REALLY good reasons not to keep running ancient and outdated DNS services (like the BIND4 that shipped on those Sun servers your organization insists on maintaining for at least 30 more years). It's a little complicated to follow if you aren't familiar with the ins and outs and quirks of DNS resolution, but here's how it works:

# this is an example of a zone file a black hat would use to poison a victim's DNS cache.
# this file is being run by the black hat on his own machine, '''at IP address 1.2.3.4'''.
#
poisoner.tld. IN SOA ns.poisoner.tld hostmaster.poisoner.tld. (34; 10800; 3600; 604800; 10;)

poisoner.tld. IN NS ns.victim.tld. # this record tells anyone asking about poisoner.tld to go to ns.victim.tld
ns.victim.tld. IN A 1.2.3.4 # this record is the sneaky one - it "helpfully" tells them that the IP
# address for ns1.victim.tld is THIS machine's IP address!

# this is the bogus version of the victim.tld zone file which the black hat runs on the same
# server as the poison file, above. After ns.victim.tld's cache is poisoned, it will actually
# send users here instead of answering their queries itself!
#
victim.tld. IN SOA ns.victim.tld hostmaster.victim.tld. (34; 10800; 3600; 604800; 10;)

victim.tld. IN NS ns.victim.tld. # these two records simply say "yes, I'll tell you all about victim.tld, don't
ns.victim.tld. IN A 1.2.3.4 # go anywhere else to ask"

www.victim.tld. IN A 1.2.3.5 # this is the IP address of a webpage chock full of spammy ads and malware

After the [[black hat]] sets up his domain and the bogus zone files above on his own server, at IP address 1.2.3.4, he asks the ''real'' nameserver for '''victim.tld''' to tell him what the IP address for '''www.poisoner.tld''' is. Since it doesn't know, it asks '''ns.poisoner.tld''', which tells it that it needs to ask '''ns.victim.tld''' ''at the IP address 1.2.3.4'' for that information. The victim caches that query result - so from here on out, even though it ''is'' '''ns.victim.tld''', if you ask it how to find '''ns.victim.tld''', it will respond with the [[black hat]]'s IP address, not its own. And since the first step of client DNS resolution is to resolve the IP address of the [[authoritative nameserver]] for a domain, that further means that from here on out, any time anybody looks up ''any'' URL in the victim.tld domain, they'll get sent to the [[black hat]]'s nameserver - which will cheerfully send them to his own webpage full of ads and malware!

The good news is, DNS cache poisoning has been fixed (by refusing to cache query results coming from servers that aren't actually authoritative for the results they are giving) in BIND since 1997. The bad news is, enough people are still running ancient legacy DNS services that there are still plenty of [[black hat]]s industriously trying to poison everything in sight just to see if it works.

Avoiding DNS cache poisoning is much simpler than understanding it: don't run outdated DNS services, make your authoritative servers non-recursive (don't let them answer questions about domains they aren't authoritative for), and wherever possible, limit public access to any caching DNS servers you run for you and/or your clients' benefit.

To learn more about poisoning, see Daniel J. Bernstein's article at http://cr.yp.to/djbdns/notes.html#poison

To see if you can be poisoned, see http://ketil.froyn.name/poison.html

== See Also ==

[[BIND (installing)]], [[BIND (configuring)]], [[BIND (managing)]]

==External Links==

[[http://www.oreilly.com/catalog/dns4/chapter/ch11.html O'Reilly's BIND book's security chapter]]

[[http://www.boran.com/security/sp/bind_hardening8.html Hardening BIND 8]]

[[http://www.boran.com/security/sp/bind9_20010430.html Hardening BIND 9]]

[[http://www.boran.com/security/sp/chrooting_bind.html Info on chroot'ing]]

[[http://sysadmin.oreilly.com/news/views_05 ... \n

.xinitrc

2012-08-06T00:11:49Z

200.38.30.168: Remove spam from goodville.

This configuration file, which should reside in your home directory, tells [[startx]] what to run aside from starting the X server and client -- e.g., a desktop environment like [[KDE]], [[gnome]], [[xfce]], etc.

If you want to start KDE, you'll have to put this line in it:
exec startkde

If you want to start XFCE, you'll have to put this line in it:
exec startxfce

If you want to start Gnome, the line is:
exec gnome-session

If your [[.xinitrc]] has one of these lines in it, it will execute the Desktop Environment when you run [[startx]]. Otherwise you'll have to run startx and feed it the Desktop Environment as an argument or run the desktop init script manually.

Another approach is to alias the desktop script to another command in your shell profile; such as placing
alias gui='startxfce'
in your .bash_profile will let you start XFCE by typing in "gui" from the CLI.

[[Category: FreeBSD for Workstations]]

Bash

2012-08-05T22:32:19Z

200.38.30.168: Remove spam.

The Bourne Again Shell (located in /bin/bash) is the default [[shell]] of the [[Linux]] operating system and is the shell that users of that system will likely be most familiar with.

One of bash's strongest features, shared with the [[Bourne shell]], is flexible output [[redirection]].

Note: Bash is ''not'' available by default in the base system, but can easily be installed from [[:Category:Ports and Packages|ports]] if desired.

See [[bash]]'s [[man]] page for more info.

see also: [http://cnswww.cns.cwru.edu/php/chet/bash/bashtop.html bash homepage]

To change your shell from one to another, run the [[chsh]] command.

To change [[bash]]'s look and feel, edit your [[shell configuration file]] -- .profile and/or [[.bashrc]] (may be called .bash_profile on older systems).

Other shells that you can install and customize for ease of use are the [[bash]], [[tcsh]], [[psh]], [[ksh]], [[zsh]].

See also [[Changing_your_shell]] and [[Gotchas, Linux]]

[[Category: Shells]]
[[Category: Ports and Packages]]
[[Category : Linux Equivalents]]