http://freebsdwiki.net/api.php?action=feedcontributions&user=Jimbo&feedformat=atomFreeBSDwiki - User contributions [en]2024-03-29T14:12:02ZUser contributionsMediaWiki 1.18.0http://freebsdwiki.net/index.php/User_talk:SidetoneUser talk:Sidetone2021-07-15T21:33:51Z<p>Jimbo: </p>
<hr />
<div>I had wrote in a document file, the edits to be made, while the system locked me out. This is why edits were made so fast, recently. [[User:Sidetone|Sidetone]] 15:08, 17 December 2014 (EST)<br />
<br />
Hey Sidetone, just out of curiosity... did you realize "Jim Salter" == "creator and owner of freebsdwiki.net" when you were trashing me as some kind of FreeBSD hater on the FreeBSD forums recently, after the Ars Technica article about the work Netgate commissioned Macy to do? [[User:Jimbo|Jimbo]] 17:32, 15 July 2021</div>Jimbohttp://freebsdwiki.net/index.php/Main_PageMain Page2015-12-05T18:16:12Z<p>Jimbo: </p>
<hr />
<div><table align="center" width="50%" border=1 cellpadding=10><tr><td>&nbsp;<br />
<h1><font color="red" size="24"><b>Want to take over freebsdwiki.net?</b></font></h1><br />
<h2>It's been more than a decade now, and I'm not really active in the FreeBSD community any more. Maintaining, updating, and keeping the spammers out of this wiki isn't really enough of a focus for me anymore, and it's probably time to either hand over the reins to someone who <i>is</i> interested in actively maintaining it, or to close the doors.<br />
<br />
If you're interested in taking over and maintaining freebsdwiki.net, send an email to <b>freebsdwiki</b> [at] <b>jrs-s dot net</b>, and we'll talk.</h2><br />
&nbsp;<br />
</td></tr></table><br />
<br />
<br />
<h1>Welcome to freebsdwiki.net.</h1><br />
<br />
This is a wiki project devoted primarily to common issues faced by new and veteran FreeBSD administrators. The goal is to create a common knowledge store which could also be referred to as "FreeBSD for the Impatient" - in other words, a place where it is easy to delve straight into simple answers about common needs and problems relating to both FreeBSD servers and their integration into other types of networks.<br />
<br />
<br />
<br />
'''[[Special : Categories | Categories]]:'''<br />
<br />
# [[:Category : Why FreeBSD? |Why FreeBSD?]]<br />
# [[:Category : Installation |Installing FreeBSD]]<br />
# [[:Category : Architecture-Specific |Architecture-Specific]]<br />
# [[:Category : Configuring FreeBSD |Configuring FreeBSD]]<br />
# [[:Category : Securing FreeBSD | Securing FreeBSD]]<br />
# [[:Category : Important Config Files |Important Config Files]]<br />
# [[:Category : System Commands |System Commands]]<br />
# [[:Category : Common Tasks |Common Tasks]]<br />
# [[:Category : FreeBSD for Workstations | FreeBSD for Workstations]] <br />
# [[:Category : FreeBSD Multimedia | FreeBSD Multimedia]]<br />
# [[:Category : FreeBSD for Servers | FreeBSD for Servers]]<br />
# [[:Category : Ports and Packages|Ports and Packages]]<br />
# [[:Category : FreeBSD Terminology |FreeBSD Terminology]]<br />
# [[:Category : Windows Equivalents |Windows Equivalents]]<br />
# [[:Category : Linux Equivalents |Linux Equivalents]]<br />
# [[:Category : Cygwin |Cygwin]]<br />
# [[:Category : New User Tips and FAQs | New User Tips and FAQs]]<br />
<br />
<br />
Please feel free to register and contribute! If you need a little help figuring out how to add articles or categories, please see [[Help:Adding Content]]. If you would like some basic guidelines on how to format your article, see [[Help:Style Guidelines]]. If you want to check out some other FreeBSD info resources, see [[External Links]].<br />
<br />
<br />
'''NOTE: If you're getting 403 Forbidden errors when you try to submit things, see [[Help:WikiSpam]].'''<br />
<br />
'''NOTE2: As of 2013-06-11, freebsdwiki.net is now closed to public registration/editing due to spambots. Sorry people, I just don't have the time to keep up with deleting the hundreds of bots that make it PAST the filters every day. :( If you're a real human and you're bright enough to figure out how to email me (at jrs-s.net), feel free to request a working login, and I'll be happy to send you one.'''</div>Jimbohttp://freebsdwiki.net/index.php/Main_PageMain Page2015-12-05T16:06:52Z<p>Jimbo: </p>
<hr />
<div><table align="center" width="50%" border=1 cellpadding=10><tr><td>&nbsp;<br />
<h1><font color="red" size="24"><b>Want to take over freebsdwiki.net?</b></font></h1><br />
<h2>It's been more than a decade now, and I'm not really active in the FreeBSD community any more. Maintaining, updating, and keeping the spammers out of this wiki isn't really enough of a focus for me anymore, and it's probably time to either hand over the reins to someone who <i>is</i> interested in actively maintaining it, or to close the doors.<br />
<br />
If you're interested in taking over and maintaining freebsdwiki.net, send an email to <b>takeover</b> [at] <b>freebsdwiki dot net</b>, and we'll talk.</h2><br />
&nbsp;<br />
</td></tr></table><br />
<br />
<br />
<h1>Welcome to freebsdwiki.net.</h1><br />
<br />
This is a wiki project devoted primarily to common issues faced by new and veteran FreeBSD administrators. The goal is to create a common knowledge store which could also be referred to as "FreeBSD for the Impatient" - in other words, a place where it is easy to delve straight into simple answers about common needs and problems relating to both FreeBSD servers and their integration into other types of networks.<br />
<br />
<br />
<br />
'''[[Special : Categories | Categories]]:'''<br />
<br />
# [[:Category : Why FreeBSD? |Why FreeBSD?]]<br />
# [[:Category : Installation |Installing FreeBSD]]<br />
# [[:Category : Architecture-Specific |Architecture-Specific]]<br />
# [[:Category : Configuring FreeBSD |Configuring FreeBSD]]<br />
# [[:Category : Securing FreeBSD | Securing FreeBSD]]<br />
# [[:Category : Important Config Files |Important Config Files]]<br />
# [[:Category : System Commands |System Commands]]<br />
# [[:Category : Common Tasks |Common Tasks]]<br />
# [[:Category : FreeBSD for Workstations | FreeBSD for Workstations]] <br />
# [[:Category : FreeBSD Multimedia | FreeBSD Multimedia]]<br />
# [[:Category : FreeBSD for Servers | FreeBSD for Servers]]<br />
# [[:Category : Ports and Packages|Ports and Packages]]<br />
# [[:Category : FreeBSD Terminology |FreeBSD Terminology]]<br />
# [[:Category : Windows Equivalents |Windows Equivalents]]<br />
# [[:Category : Linux Equivalents |Linux Equivalents]]<br />
# [[:Category : Cygwin |Cygwin]]<br />
# [[:Category : New User Tips and FAQs | New User Tips and FAQs]]<br />
<br />
<br />
Please feel free to register and contribute! If you need a little help figuring out how to add articles or categories, please see [[Help:Adding Content]]. If you would like some basic guidelines on how to format your article, see [[Help:Style Guidelines]]. If you want to check out some other FreeBSD info resources, see [[External Links]].<br />
<br />
<br />
'''NOTE: If you're getting 403 Forbidden errors when you try to submit things, see [[Help:WikiSpam]].'''<br />
<br />
'''NOTE2: As of 2013-06-11, freebsdwiki.net is now closed to public registration/editing due to spambots. Sorry people, I just don't have the time to keep up with deleting the hundreds of bots that make it PAST the filters every day. :( If you're a real human and you're bright enough to figure out how to email me (at jrs-s.net), feel free to request a working login, and I'll be happy to send you one.'''</div>Jimbohttp://freebsdwiki.net/index.php/Main_PageMain Page2013-06-11T06:54:18Z<p>Jimbo: </p>
<hr />
<div>'''Welcome to FreeBSDwiki.net.'''<br />
<br />
This is a wiki project devoted primarily to common issues faced by new and veteran FreeBSD administrators. The goal is to create a common knowledge store which could also be referred to as "FreeBSD for the Impatient" - in other words, a place where it is easy to delve straight into simple answers about common needs and problems relating to both FreeBSD servers and their integration into other types of networks.<br />
<br />
<br />
'''[[Special : Categories | Categories]]:'''<br />
<br />
# [[:Category : Why FreeBSD? |Why FreeBSD?]]<br />
# [[:Category : Installation |Installing FreeBSD]]<br />
# [[:Category : Architecture-Specific |Architecture-Specific]]<br />
# [[:Category : Configuring FreeBSD |Configuring FreeBSD]]<br />
# [[:Category : Securing FreeBSD | Securing FreeBSD]]<br />
# [[:Category : Important Config Files |Important Config Files]]<br />
# [[:Category : System Commands |System Commands]]<br />
# [[:Category : Common Tasks |Common Tasks]]<br />
# [[:Category : FreeBSD for Workstations | FreeBSD for Workstations]] <br />
# [[:Category : FreeBSD Multimedia | FreeBSD Multimedia]]<br />
# [[:Category : FreeBSD for Servers | FreeBSD for Servers]]<br />
# [[:Category : Ports and Packages|Ports and Packages]]<br />
# [[:Category : FreeBSD Terminology |FreeBSD Terminology]]<br />
# [[:Category : Windows Equivalents |Windows Equivalents]]<br />
# [[:Category : Linux Equivalents |Linux Equivalents]]<br />
# [[:Category : Cygwin |Cygwin]]<br />
# [[:Category : New User Tips and FAQs | New User Tips and FAQs]]<br />
<br />
<br />
Please feel free to register and contribute! If you need a little help figuring out how to add articles or categories, please see [[Help:Adding Content]]. If you would like some basic guidelines on how to format your article, see [[Help:Style Guidelines]]. If you want to check out some other FreeBSD info resources, see [[External Links]].<br />
<br />
<br />
'''NOTE: If you're getting 403 Forbidden errors when you try to submit things, see [[Help:WikiSpam]].'''<br />
<br />
'''NOTE2: As of 2013-06-11, freebsdwiki.net is now closed to public registration/editing due to spambots. Sorry people, I just don't have the time to keep up with deleting the hundreds of bots that make it PAST the filters every day. :( If you're a real human and you're bright enough to figure out how to email me (at jrs-s.net), feel free to request a working login, and I'll be happy to send you one.'''</div>Jimbohttp://freebsdwiki.net/index.php/Default_denyDefault deny2013-02-19T16:38:32Z<p>Jimbo: Reverted edits by 115.244.8.26 (talk) to last revision by Jimbo</p>
<hr />
<div>'''Default Deny''' is a type of [[firewall]] ruleset in which the default condition of the firewall is to deny ALL connectivity - from anywhere, to anywhere. A '''default deny''' firewall with no additional rules loaded effectively has no network interfaces in it at all.<br />
<br />
You do need to be careful in how you manipulate a default deny system - for instance, if you try to reload the firewall rules remotely, you'll kill it (since the shell session will terminate as soon as the system returns to default rules, thereby never getting the chance to load the extra rules that allow some types of connectivity). However, default deny is the recommended type of firewall ruleset, because while a '''default allow''' setup would not have the problem outlined above, it ''would'' be vulnerable to a [[race condition]] in which an attacker could compromise the system by attacking it in the period between the reset to the default allow ruleset and reloading of additional rules to restrict access afterwards.<br />
<br />
All FreeBSD systems running [[ipfw]] are automatically '''default deny''' systems unless specified otherwise in a [[custom kernel]], with the line '''options IPFIREWALL_DEFAULT_TO_ACCEPT'''. For the [[race condition]] reason outlined above, it is NOT recommended that you override this behavior to force a '''default allow''' ruleset.<br />
<br />
see also: [[Firewall, Configuring]]<br />
[[Category:FreeBSD Terminology]]<br />
[[Category:Securing FreeBSD]]</div>Jimbohttp://freebsdwiki.net/index.php/RAMdisks,_creating_under_FreeBSD_5.xRAMdisks, creating under FreeBSD 5.x2012-10-06T05:37:44Z<p>Jimbo: Reverted edits by Janhouston (talk) to last revision by Jimbo</p>
<hr />
<div>I invariably get irritated and confused by [[mdconfig]]'s syntax, since I need it just often enough to never remember how to use it, and no more. And most of the readily google-able documentation on the web covers FreeBSD 4.x's [[vnconfig]] instead, which is useless if you're running a 5.x system. So I just wrote myself a handy little shell script named '''makeramdisk.sh''' that I keep in my home directory for reference's sake:<br />
<br />
#!/bin/sh<br />
<br />
case "$1" in<br />
start)<br />
/sbin/mdconfig -a -t malloc -s 256M -u 10<br />
/sbin/newfs -U /dev/md10<br />
/sbin/mount /dev/md10 /mnt/ramdisk<br />
echo "256MB ramdisk created on /dev/md10 and mounted on /mnt/ramdisk"<br />
exit 0<br />
;;<br />
stop)<br />
/sbin/umount /mnt/ramdisk<br />
/sbin/mdconfig -d -u 10<br />
echo "ramdisk unmounted from /mnt/ramdisk and deleted from /dev/md10"<br />
;;<br />
*)<br />
echo "Usage: `basename $0` {start|stop}" >&2<br />
exit 64<br />
;;<br />
esac<br />
<br />
Under FreeBSD 6.x (and possibly under 5.x as well), the first three lines of the start section can be combined into a single line, as per the below.<br />
<br />
#!/bin/sh<br />
<br />
case "$1" in<br />
start)<br />
/sbin/mdmfs -s 256M md10 /mnt/ramdisk<br />
echo "256MB ramdisk created on /dev/md10 and mounted on /mnt/ramdisk"<br />
exit 0<br />
;;<br />
stop)<br />
/sbin/umount /mnt/ramdisk<br />
/sbin/mdconfig -d -u 10<br />
echo "ramdisk unmounted from /mnt/ramdisk and deleted from /dev/md10"<br />
;;<br />
*)<br />
echo "Usage: `basename $0` {start|stop}" >&2<br />
exit 64<br />
;;<br />
esac<br />
<br />
To use this script, you would type '''makeramdisk.sh start''' or '''makeramdisk.sh stop''' to create and mount, or dismount and delete, respectively, a 256MB RAMdisk on /dev/md10. (Note: the script as written depends on the prior existence of a directory at '''/mnt/ramdisk'''. If that directory does not exist, you're going to have problems.)<br />
<br />
You should be able to figure out from the examples what you'd need to do different to change the size of the drive, where you mount it, etc.<br />
[[Category : Common Tasks]]</div>Jimbohttp://freebsdwiki.net/index.php/Mplayer_InstallationMplayer Installation2012-10-06T05:37:29Z<p>Jimbo: Reverted edits by Janhouston (talk) to last revision by Jimbo</p>
<hr />
<div>see also [[Mplayer]]<br />
<br />
This is a quick guide to installing the Mplayer port.<br />
<br />
(optional) Before you install Mplayer you should probably get the codecs that you want from [http://www.mplayerhq.hu/homepage/design7/dload.html mplayerhq.hu] and put them in /usr/local/lib/codecs. Note the disclaimer: ''There is absolutely no warranty of any kind for these codec packages. Copyrights of all DLLs remain with their respective owner(s). You should be aware that some of these DLLs have licenses that restrict them to use with certain programs. We only distribute them, the rest is your responsibility.''<br />
<br />
> '''su'''<br />
Password: (enter root password)<br />
> '''mkdir /usr/local/lib/codecs'''<br />
> '''cd /tmp/'''<br />
> '''wget http://www1.mplayerhq.hu/MPlayer/releases/codecs/all-20050115.tar.bz2'''<br />
> '''bunzip2 all-20050115.tar.bz2'''<br />
> '''tar -xf all-20050115.tar'''<br />
> '''cd /usr/local/lib/codecs'''<br />
> '''cp /tmp/all-20050115/* .'''<br />
<br />
Now installing Mplayer can be as complicated as you want the following example is very simple.<br />
<br />
> '''su'''<br />
Password: (enter root password)<br />
> '''cd /usr/ports/multimedia/mplayer'''<br />
> '''make WITH_GUI=yes install clean'''<br />
<br />
Before you run Mplayer you need to install the fonts,<br />
<br />
> '''cd /usr/ports/multimedia/mplayer-fonts'''<br />
> '''make install clean'''<br />
<br />
create your user settings, <br />
> '''su nvrmnd'''<br />
Password: (enter nvrmnd's password)<br />
> '''cd /usr/ports/multimedia/mplayer'''<br />
> '''make install-user'''<br />
> '''cp /usr/local/share/mplayer/codecs.conf ~/.mplayer/'''<br />
> '''cp /usr/local/share/mplayer/example.conf ~/.mplayer/config'''<br />
> '''cp /usr/local/share/mplayer/input.conf ~/.mplayer'''<br />
<br />
add atleast one skin from [http://www.mplayerhq.hu/homepage/design7/dload.html mplayerhq.hu],<br />
> '''su nvrmnd'''<br />
Password: (enter nvrmnd's password)<br />
> '''mkdir ~/.mplayer/Skin<br />
> '''cd ~/.mplayer/Skin'''<br />
> '''wget http://www1.mplayerhq.hu/MPlayer/Skin/Blue-1.4.tar.bz2'''<br />
> '''bunzip2 Blue-1.4.tar.bz2'''<br />
> '''tar -xf Blue-1.4.tar'''<br />
<br />
and edit ~/.mplayer/config comment out the last line:<br />
include = /home/gabucino/.mplayer/i_did_not_RTFM_carefully_enough...<br />
<br />
you can run Mplayer with a gui wth the '''gmplayer''' command. The command line player is '''mplayer'''.<br />
<br />
== External links ==<br />
[http://lists.freebsd.org/pipermail/freebsd-questions/2003-October/023709.html Configuration example]<br />
<br />
[[Category:Common Tasks]]</div>Jimbohttp://freebsdwiki.net/index.php/MegarcMegarc2012-10-06T05:37:01Z<p>Jimbo: Reverted edits by 94.23.1.28 (talk) to last revision by 75.150.37.150</p>
<hr />
<div>[[Category:Ports and Packages]] [[Category:RAID]]<br />
'''''{{PAGENAME}}''''' is a commandline utility that provides an interface to many of the configuration and reporting functions for LSI Logic's MegaRAID BIOS (http://www.lsilogic.com). <br />
<br />
==Megarc port for FreeBSD==<br />
The ''megarc'' utility ships as a binary, without any accompanying documentation, on the "Megaraid Universal Software Suite" CD which accompanies any boxed LSI Logic RAID storage adapter. It is also found in the FreeBSD ports collection.<br />
<br />
* On the CD that comes with the storage adapter, the utility is found in two places. It is part of a zipped bundle in <cd>:\SW_Components\Drivers\dr_freebsd_1.51.zip on our distribution. The zip file contents are as follows:<br />
<br />
<pre><br />
Length Date Time Name<br />
-------- ---- ---- ----<br />
130448 04-18-05 14:10 MegaRC 1.04.zip<br />
12953 10-08-04 16:05 amr_x86_64_ver1_51FreeBSD5.3.tgz<br />
153600 03-17-05 15:19 code.tar<br />
535 02-10-05 11:02 FreeBSDDriverUpdate.txt<br />
12774 10-12-04 19:38 amr_i386_ver_1_51_FreeBSD5.3.tgz<br />
-------- -------<br />
310310 5 files<br />
</pre><br />
<br />
* The utility is also found on the CD by itself, at "<cd>:\SW_Components\Utilities\ut_FreeBSD_MegaRC 1.04.zip".<br />
<br />
* It can be downloaded from LSI at http://www.lsi.com/downloads/Public/MegaRAID%20Common%20Files/dr_freebsd_1.51.zip<br />
<br />
* It can be also be installed from the [http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/megarc/ ports collection] at /usr/ports/sysutils/megarc. The port extracts the binary from the bundled dr_freebsd_*.zip Our example was installed from the ports collection on 6.1-PRERELEASE FreeBSD amd64<br />
<br />
<br />
<pre><br />
# file /usr/local/sbin/megarc<br />
/usr/local/sbin/megarc: ELF 32-bit LSB executable, Intel 80386,<br />
version 1 (FreeBSD), for FreeBSD 5.2.1, statically linked, stripped<br />
</pre><br />
<br />
==Documentation==<br />
The documentation for megarc is limited to the output of its ?/help functions. Since these [[RAID]] adapters are reasonably popular, and the commands are a bit scary and somewhat obscurely named, this page might prove helpful to someone even though it's not complete. <br />
<br />
Megarc must be run with sufficient privileges, or the adapter will not be found. "?" and "help" are not synonymous. ''?'' (mis-named "complete help") gives brief syntax hints. ''help'' gives a fuller description of what the command does, and its arguments and usage. <br />
<br />
* To see the commands available, as root type:<br /><code>megarc ?</code><br />
First Parameter should be :<br />
-AllAdpInfo <br />
... etc ...<br />
*To see a list of commands and syntax, type:<br /> <code>megarc help</code><br />
<pre><br />
-------------------------------------------------------------------------<br />
* Convention Used:<br />
[Cmd = The name of the utility]<br />
opt1|opt2|opt3 => Only one of these can be specified<br />
<br />
-------------------------------------------------------------------------<br />
Cmd ?: Gives complete help<br />
Cmd -functionality ?: functionality specific help<br />
Example:<br />
Cmd -ctlrInfo ? :help on -ctlrinfo option<br />
<br />
-------------------------------------------------------------------------<br />
Usage: Cmd -ctlrInfo -aX <br />
... etc ...<br />
</pre><br />
* '''Example:'''<br /> <code> megarc -ctlrInfo help </code><br />
<pre><br />
**********************************************************************<br />
<br />
usage :<br />
cmd -ctlrInfo -aX<br />
: Shows general adapter info of adapter<br />
**********************************************************************<br />
where :<br />
cmd : name of the utility<br />
-aX : adapter number X(max 12 adapters). X=0..11<br />
**********************************************************************<br />
</pre><br />
<br />
==Examples==<br />
For the examples below, we are using an LSILogic 150-6 x64 SATA RAID adapter on a 32-bit PCI slot - "adapter 0" on the system - with a RAID 5 volume consisting of five (5) physical SATA drives of 400GB each. The hot-spare belongs to target 00 but is being replaced at the time of this writing.<br />
<br />
Below are some brief descriptions of some of the commands, and some examples of output from a few of the information functions. These command-options are not case-sensitive.<br />
<br />
===megarc -dispCfg -a0 ===<br />
Display the configuration for adapter ''0''.<br />
<br />
<pre><br />
Logical Drive : 0( Adapter: 0 ): Status: OPTIMAL<br />
---------------------------------------------------<br />
SpanDepth :01 RaidLevel: 5 RdAhead : No Cache: DirectIo<br />
StripSz :064KB Stripes : 5 WrPolicy: WriteThru<br />
<br />
Logical Drive 0 : SpanLevel_0 Disks<br />
Chnl Target StartBlock Blocks Physical Target Status<br />
---- ------ ---------- ------ ----------------------<br />
0 01 0x00000000 0x2e936800 ONLINE<br />
0 02 0x00000000 0x2e936800 ONLINE<br />
0 03 0x00000000 0x2e936800 ONLINE<br />
0 04 0x00000000 0x2e936800 ONLINE<br />
0 05 0x00000000 0x2e936800 ONLINE<br />
</pre><br />
<br />
===megarc -LogPhysInfo -a0 ===<br />
Display the physical drive information for each of the logical drives on adapter ''0''.<br />
<br />
<pre><br />
Logical drive 0: RaidLevel 5<br />
<br />
Physical Drive Information<br />
Channel 0<br />
381549MB drive ID 1<br />
CoerSZ: 781412352(Sectors) 381549(MB) RawSZ: 781422255(Sectors)<br />
381549MB drive ID 2<br />
CoerSZ: 781412352(Sectors) 381549(MB) RawSZ: 781422255(Sectors)<br />
381549MB drive ID 3<br />
CoerSZ: 781412352(Sectors) 381549(MB) RawSZ: 781422255(Sectors)<br />
381549MB drive ID 4<br />
CoerSZ: 781412352(Sectors) 381549(MB) RawSZ: 781422255(Sectors)<br />
381549MB drive ID 5<br />
CoerSZ: 781412352(Sectors) 381549(MB) RawSZ: 781422255(Sectors)<br />
<br />
</pre><br />
<br />
===megarc -ScfgAndParm|-DfcfgAndParm|-RcfgAndParm -fFileName -a0 ===<br />
Save, Display, or Restore the configuration and parameters for adapter ''0'', in ''FileName''. ''FileName'' stores the same output provided by -dispCfg in a binary format, making it possible to directly load the stored configuration from the file.<br />
<br />
===megarc -physOn pd[c0:t0,c1:t1....] -a0===<br />
<br />
Set the state of the designated drive(s) to ''Online''. ''pd[c:t]'' refers to at least one physical drive by channel and target. ''-aN'' here as elsewere is the adapter number [required]<br />
<br />
If the physical drive does not exist or if it isn't in failed state, the utility exits with no harm done.<br />
<br />
An example of this command under our present configuration would be: <br />
megarc -physOn -a0 pd[0:1]<br />
<br />
===megarc -phys -chAll -idAll -a0===<br />
Show the physical drive description for each device on all channels managed by adapter ''0''<br />
<br />
<pre><br />
<br />
Adapter 0, Channel 0, Target ID 1 <br />
Type: DISK Vendor : WDC<br />
Product: WD4000KD-00NAB0 Revision : 01.0<br />
Synchronous : No Wide-32 : No Wide-16: No<br />
LinkCmdSupport: No TagQ support: No RelAddr: No<br />
Removable : No SoftReset : No AENC : No<br />
etc...<br />
</pre><br />
<br />
===megarc -physdrvSerialInfo -chAll -idAll -a0===<br />
Show the serial number for each physical drive on each channel for all serial devices managed by adapter ''0'' (This doesn't look correct or helpful).<br />
<br />
<pre><br />
Adapter 0, Channel 0, Target ID 1 <br />
<br />
PhysDrvSerial#: WD-W<br />
<br />
etc ...<br />
</pre><br />
<br />
===megarc -pdFailInfo -chAll -idAll -a0===<br />
Show the failure history for each device on all channels managed by adapter ''0''. <br />
<br />
===megarc -setRbldRate|-getRbldRate -a0 ===<br />
Get the rebuild rate for adapter ''0''.<br />
<pre><br />
<br />
# megarc -getRbldRate -a0<br />
<br />
...<br />
<br />
**********************************************************************<br />
RebuildRate of Adapter-0 is 30<br />
**********************************************************************<br />
</pre><br />
<br />
===megarc -ctlrInfo -a0===<br />
Display information about adapter ''0''.<br />
<br />
<pre><br />
**********************************************************************<br />
Information of Adapter-0 (#Adapter(s) on system: 1)<br />
**********************************************************************<br />
<br />
Firmware Version : 713N BIOS Version : G119<br />
Logical Drives : 01 DRAM : 64MB<br />
Rebuild Rate : 30%<br />
Flush Interval : 4 secs<br />
Number Of Chnls : 1 Bios Status : Enabled<br />
Alarm State : Enabled Auto Rebuild : Enabled<br />
FW : SPAN-8, 40-LD BIOS Config AutoSelection : USER<br />
BIOS Echos Mesg : ON BIOS Stops On Error : ON<br />
Initiator Id : 16(Clustered Firmware)<br />
Board SN: -17179869<br />
**********************************************************************<br />
</pre><br />
<br />
===megarc -getXFerRate|-setXFerRate -a0 -chAll===<br />
Get or set the transfer rate for all channels on adapter ''0''.<br />
<pre><br />
# megarc -getXFerRate -a0 -ch0<br />
<br />
**********************************************************************<br />
Transfer Rate of Adapter-0 Channel-0 is 160M<br />
**********************************************************************<br />
</pre></div>Jimbohttp://freebsdwiki.net/index.php/FirewallFirewall2012-08-25T22:14:12Z<p>Jimbo: </p>
<hr />
<div><br />
== Firewalls ==<br />
All software firewall applications are based on monitoring network packet traffic flow to and from your system. The values of selected packet control fields can be interrogated by user written rules to allow or deny packet traffic based on your security needs. <br />
<br />
Selection can be based on source and destination IP address, the source and destination port number, the type of protocol used (TCP, UDP, ICMP), or any combination. Firewall software applications provide a much, much finer level of control than that provided by a hardware router. They can be used to protect a single FBSD system or a complete internal network (LAN) by preventing public Internet traffic from making arbitrary connections to your internal network. They may also be used to prevent public Internet entities from spoofing internal IP addresses and to disable services you do not want accessed from the public Internet or by internal LAN users.<br />
<br />
Finally, firewalls may be used to support NAT (network address translation), which allows an internal network using private IP addresses to share a single connection to the public Internet, or letting commercial users share a range of static public IP addresses automatically among the LAN users.<br />
<br />
<br />
<br />
<br />
== Firewall Rule Set Types ==<br />
Constructing a software application firewall rule set may seem to be trivial, but most people get it wrong. The most common mistake is to create an exclusive firewall rather than an inclusive firewall. <br />
<br />
An exclusive firewall allows all services through except for those matching a set of rules that block certain services. <br />
<br />
An inclusive firewall does the reverse. It only allows services matching the rules through and blocks everything else. This way you can control what services can originate behind the firewall destined for the public Internet and also control which services originating from the public Internet may access your network. Inclusive firewalls are much, much safer than exclusive firewalls. <br />
<br />
When you use your browser to access a web site there are many internal functions that happen before your screen fills with the data from the target web site. Your browser does not receive one large file containing all the data and display format instructions at one time. Each internal function accesses the public Internet in multiple send/receive cycles of packets of information. When all the packets containing the data finally arrive, the data contained in the packets is combined together to fill your screen. Each service has its own port number. The port number 80 is for web page services. So you can code your firewall to only allow web page session start requests originating from your LAN to pass through the firewall out to the public Internet. <br />
<br />
Security can be tightened further by telling the firewall to monitor the send/receive cycles of all the packets making up that session until the session completes. These are called stateful capabilities and provide the maximum level of protection. <br />
<br />
A firewall rule set that does not implement stateful capabilities on all the services being authorized is an insecure firewall that is still open to many of the most common methods of attack. <br />
<br />
<br />
<br />
<br />
== Firewall Software Applications ==<br />
FBSD has three different firewall software products built into the base system. They are IPFILTER also known as IPF, IPFIREWALL also known as IPFW, and the OpenBSD Packet Filter known as PF. IPFW has the built in traffic shaper facilities for controlling bandwidth usage called dummynet. PF has it's built in traffic shaper facilities for controlling bandwidth usage called ALTQ. IPFILTER does not have a built in traffic shaper facility for controlling bandwidth usage, but the ALTQ port application can be used to accomplish the same function. The dummynet feature and ALTQ is generally useful only to large ISPs or commercial users. IPF, IPFW, and IP use rules to control the access of packets to and from your system, although they go about it different ways and have different rule syntaxes. <br />
<br />
The IPFW /etc/rc.firewall sample rule set delivered in the basic install is outdated, complicated and does not use stateful rules on the interface facing the public Internet. It exclusively uses legacy stateless rules which only have the ability to open or close the service ports. The IPFW example stateful rule sets presented here supercedes the /etc/rc.firewall file distributed with the system. <br />
<br />
Stateful rules have technically advanced interrogation abilities capable of defending against the flood of different attack methods currently employed by attackers.<br />
<br />
Both of these firewall software solutions IPF and IPFW still maintain the legacy heritage of their original rule processing order and reliance on non-stateful rules. These outdated concepts are not covered here, only the new, modern stateful rule construct and rule processing order is presented. <br />
<br />
You should read about all 3 firewalls, and them make your own decision on which one best fits your needs. <br />
<br />
The author prefers IPFILTER because its stateful rules are much less complicated to use in a Nat environment, and it has a built in FTP proxy that simplifies the rules to allow secure outbound FTP usage. It is also more appropriate to the knowledge level of the inexperienced firewall user. <br />
<br />
Since all firewalls are based on interrogating the values of selected packet control fields, the creator of the firewall rules must have an understanding of how TCP/IP works, what the different values in the packet control fields are and how these values are used in a normal session conversation. For a good explanation go to http://www.ipprimer.com/overview.cfm.<br />
<br />
<br />
<br />
<br />
[[Category:Securing FreeBSD]]<br />
[[Category: FreeBSD Terminology]]<br />
[[Category:Firewall]]</div>Jimbohttp://freebsdwiki.net/index.php/PatchingPatching2012-08-25T22:12:59Z<p>Jimbo: Reverted edits by 173.88.199.104 (talk) to last revision by Jimbo</p>
<hr />
<div>One of the blesses and curses of the open source world is that since you can get everything in readable and editable form, you can '''patch''' a program in order to make a specific alteration to it or upgrade it. This may be to fix a bug, to make a minor alteration to suit your system or your particular needs or to add a new capability. <br />
<br />
Often enough you will have to patch files manually, or share a bug fix with someone using [[diff]].<br />
<br />
=== Sharing a bug fix ===<br />
<br />
Let's say you have those two files, "file" and "fixedfile":<br />
<br />
file:<br />
<br />
Code<br />
Bug<br />
Code<br />
<br />
fixedfile:<br />
<br />
Code<br />
Code<br />
New feature<br />
<br />
and "fixedfile" is the fixed/improved version of "file", and you want to create your own patch using [[diff]] so that others can take advantage of your fix by patching the original source with it.<br />
<br />
Use this command (make sure "fixedfile" goes after "file")<br />
<br />
diff -u file fixedfile > fix<br />
<br />
This will create a file called "fix" with this content<br />
<br />
{<br />
--- file Mon Jan 3 19:14:28 2005<br />
+++ fixedfile Mon Jan 3 19:15:01 2005<br />
@@ -1,4 +1,4 @@<br />
Something<br />
-bug<br />
Something<br />
+New feature<br />
}<br />
<br />
<br />
You can now publish, archive, or Email this patch.<br />
<br />
In real life situations patches are often hundreds of time smaller than sending the whole fixed file so they are convenient.<br />
<br />
=== Patch a file ===<br />
<br />
You have this file called "file"<br />
<br />
file<br />
<br />
Code<br />
Bug<br />
Code<br />
<br />
Which you want patched with "fix" which you got from an Email<br />
<br />
{<br />
Hello friend, try this to get rid of the bug!<br />
<br />
--- file Mon Jan 3 19:14:28 2005<br />
+++ fixedfile Mon Jan 3 19:15:01 2005<br />
@@ -1,4 +1,4 @@<br />
Something<br />
-bug<br />
Something<br />
+New feature<br />
<br />
Blah, blah, and the new feature is cool!<br />
}<br />
<br />
All you have to do is put "fix" in the same directory as "file", and use the [[patch]] command like this:<br />
patch <fix<br />
<br />
You need not have the file "fix" perfectly cleaned up if it was posted; you can cut-and-paste an Email message with a diff file in the middle and it will work!<br />
<br />
=== Undo a patch ===<br />
<br />
If you don't like the patch for some reason, you can type again<br />
<br />
patch <fix<br />
<br />
you will get a prompt asking<br />
<br />
"Reversed (or previously applied) patch detected! Assume -R? [y]"<br />
<br />
Type 'y' to undo all of the patch in "fix". If "fix" were a group of patches, you can type 'n' and type 'y' on the next prompt to reverse only one patch rather than the whole content of "fix".<br />
<br />
You can also use<br />
<br />
patch -R <fix<br />
<br />
This reverses all patches in "fix" without any prompt.<br />
<br />
=== Useful to know ===<br />
<br />
The patch command can patch multiple files at once, usually from a group of diff files put together.<br />
<br />
patch can still work if line number are off (usually due to skipping certain patches). However this can on occasion not do the right thing so backups are recommended. Consult the man page for more.<br />
<br />
<br />
[[Category:Common Tasks]] [[Category:FreeBSD Terminology]][[Category:FreeBSD for Servers]]<br />
[[Category:Securing FreeBSD]]</div>Jimbohttp://freebsdwiki.net/index.php/Default_denyDefault deny2012-08-25T22:12:47Z<p>Jimbo: Reverted edits by 173.88.199.104 (talk) to last revision by Jimbo</p>
<hr />
<div>'''Default Deny''' is a type of [[firewall]] ruleset in which the default condition of the firewall is to deny ALL connectivity - from anywhere, to anywhere. A '''default deny''' firewall with no additional rules loaded effectively has no network interfaces in it at all.<br />
<br />
You do need to be careful in how you manipulate a default deny system - for instance, if you try to reload the firewall rules remotely, you'll kill it (since the shell session will terminate as soon as the system returns to default rules, thereby never getting the chance to load the extra rules that allow some types of connectivity). However, default deny is the recommended type of firewall ruleset, because while a '''default allow''' setup would not have the problem outlined above, it ''would'' be vulnerable to a [[race condition]] in which an attacker could compromise the system by attacking it in the period between the reset to the default allow ruleset and reloading of additional rules to restrict access afterwards.<br />
<br />
All FreeBSD systems running [[ipfw]] are automatically '''default deny''' systems unless specified otherwise in a [[custom kernel]], with the line '''options IPFIREWALL_DEFAULT_TO_ACCEPT'''. For the [[race condition]] reason outlined above, it is NOT recommended that you override this behavior to force a '''default allow''' ruleset.<br />
<br />
see also: [[Firewall, Configuring]]<br />
[[Category:FreeBSD Terminology]]<br />
[[Category:Securing FreeBSD]]</div>Jimbohttp://freebsdwiki.net/index.php/IpfwIpfw2012-08-25T22:11:48Z<p>Jimbo: </p>
<hr />
<div>'''ipfw''' is the kernel firewall used by FreeBSD systems. If you want to run '''ipfw''', you need to create a firewall ruleset and the system will dynamically load the kernel module when the rc.conf statement firewall_enable="YES" is used. You do not need to compile IPFW into the FreeBSD kernel unless you want NAT function enabled. If you '''do''' plan on NAT'ing, you'll need to [[Custom Kernel|build a custom kernel]] with several '''ipfw'''-related options.<br />
<br />
see also: [[Firewall, Configuring]], [[Firewall, Monitoring]]<br />
[[Category:System Commands]]<br />
[[Category:Securing FreeBSD]]<br />
[[Category:Firewall]]</div>Jimbohttp://freebsdwiki.net/index.php/Category:Securing_FreeBSDCategory:Securing FreeBSD2012-08-25T22:11:09Z<p>Jimbo: Reverted edits by 173.88.199.104 (talk) to last revision by Jimbo</p>
<hr />
<div>If you're serious about running a server that will get any public (i.e., untrusted) traffic, you ''must'' secure your server. There are many people that will want to take advantage of your server for a multitude of reasons. Although FreeBSD's security record rivals many other operating systems, and it is pretty secure by default, there are many things that you can do to secure your box further and provide a safer environment for your system and it's users.<br />
<br />
<br />
If you want your article to appear in this category, simply add the tag '''<nowiki>[[Category:Securing FreeBSD]]</nowiki>''' to its end.</div>Jimbohttp://freebsdwiki.net/index.php/NatdNatd2012-08-25T22:09:54Z<p>Jimbo: </p>
<hr />
<div>{{stub}}<br />
<br />
'''natd''' is the system daemon that handles [[Network Address Translation]] for FreeBSD systems acting as [[gateway]]s. Its behavior is controlled both through the use of command line switches and a configuration file, typically located at /etc/[[natd.conf]].<br />
<br />
see also: [[Firewall, Configuring]]<br />
<br />
[[Category:System Commands]]<br />
[[Category:Firewall]]</div>Jimbohttp://freebsdwiki.net/index.php/Firewall,_MonitoringFirewall, Monitoring2012-08-25T22:09:10Z<p>Jimbo: Reverted edits by 173.88.199.104 (talk) to last revision by Jimbo</p>
<hr />
<div>I wrote myself a handy little CGI application in Perl to let me monitor my [[ipfw]] firewall from a web browser. It uses (optional) reverse DNS host lookups for the source IPs of the things you're logging, (optional) service lookups from [[ /etc/services]] for the destination port numbers, and (optional) service override lookups for things that you want to look different in the firewall than in /etc/services. (I personally like to put attack types and such in the overrides file, WITHOUT necessarily winding up obliterating legitimate services that may also use that particular port in my /etc/services file.)<br />
<br />
You can specify alternate logfiles for it to read from the HTTP address, in the format '''<nowiki>http://youraddress/ipfwparser.cgi?logfile=/var/log/security.0.gz</nowiki>''' here, if you like. Don't sweat GZIPped or BZIP2ed logs; as long as you make sure that the locations of [[gzcat]] and [[bzcat]] specified in the config section are correct (and that you are using .gz and .bz2 extensions on any compressed logfiles), it'll handle the compressed logs transparently.<br />
<br />
One common "gotcha" to remember: if you want this to work from a web browser, you'll need to make sure that your firewall log is readable from the user context of your webserver (in most cases, the user 'www'). Usually you'll want to do this by [[chmod]]ding /var/log/security to 644 - and don't forget to change the value in [[/etc/newsyslog.conf]] as well, or it'll be overwritten the first time your logs rotate!<br />
<br />
<nowiki>#! /usr/bin/perl<br />
<br />
##<br />
## ipfwparser.cgi - (c) 2004 Jim Salter<br />
## Version 1.0, 2004 Nov 13<br />
##<br />
## this script is open source software. you may use it under the terms<br />
## of the GNU GPL - you may use it, alter it, redistribute it, and <br />
## redistribute any alterations you make as well. Any changes you make<br />
## must also be made available to the public under the same terms. No <br />
## warranties express or implied are made, and you use this software at <br />
## your own risk.<br />
##<br />
## See http://www.opensource.org/licenses/gpl-license.php for a complete<br />
## copy of the GNU GPL.<br />
##<br />
<br />
#########<br />
######### Config Section<br />
#########<br />
<br />
# gzcat utility is used to read GZIP compressed logfiles<br />
$gzcat = "/usr/bin/gzcat";<br />
<br />
# bzcat utility is used to read BZIP2 compressed logfiles<br />
$bzcat = "/usr/bin/bzcat";<br />
<br />
# location of default logfile - may be overridden with HTTP GET or POST arguments <br />
$in{'logfile'} = "/var/log/security";<br />
<br />
# dig command and options are used for reverse DNS lookup<br />
$dig_cmd = "/usr/bin/dig -x";<br />
$dig_opts = "+short +time=1 +tries=1";<br />
$host_lookups = 1;<br />
<br />
# use service lookups from /etc/services and optional overrides from elsewhere<br />
$service_lookups = 1;<br />
$service_overrides = '/usr/local/etc/service_overrides';<br />
<br />
# get HTTP GET and POST arguments<br />
&ReadParse;<br />
<br />
# munge $in{'logfile'} if we see extensions indicating compressed logs <br />
if ($in{'logfile'} =~ m/\.gz$/) {$in{'logfile'} = "$gzcat $in{'logfile'} |";}<br />
if ($in{'logfile'} =~ m/\.bz2$/) {$in{'logfile'} = "$bzcat $in{'logfile'} |";}<br />
<br />
#########<br />
#########<br />
#########<br />
<br />
<br />
#### read logfile into an array<br />
<br />
my $counter = 0; # for use iterating through the array<br />
open FH, "$in{'logfile'}";<br />
<br />
foreach (&lt;FH>) {<br />
chomp();<br />
@templine = split (/\s+/, $_);<br />
<br />
# datestamp<br />
$log[$counter][1] = $templine[0] . '&nbsp;' . $templine[1] . '&nbsp;' . $templine[2];<br />
<br />
# hostname<br />
$log[$counter][2] = $templine[3];<br />
<br />
# check for "last message repeated"<br />
if ($templine[4] ne "last") {<br />
# count of specific action<br />
$log[$counter][0] = 1;<br />
# rule number<br />
$log[$counter][3] = $templine[6];<br />
# action<br />
$log[$counter][4] = $templine[7];<br />
# protocol<br />
$log[$counter][5] = $templine[8];<br />
# source address and port<br />
my @source = split (/:/, $templine[9]);<br />
$log[$counter][6] = $source[0];<br />
$log[$counter][7] = $source[1];<br />
# destination address and port<br />
my @destination = split (/:/, $templine[10]);<br />
$log[$counter][8] = $destination[0];<br />
$log[$counter][9] = $destination[1];<br />
<br />
# direction<br />
$log[$counter][10] = $templine[11];<br />
# interface<br />
$log[$counter][11] = $templine[13];<br />
# check for ICMP in [5] and split out protocol as ports if so<br />
my @ICMP = split (/:/,$log[$counter][5]);<br />
if ($ICMP[0] eq 'ICMP') {<br />
$log[$counter][5] = 'ICMP';<br />
$log[$counter][7] = $ICMP[1];<br />
$log[$counter][9] = $ICMP[1];<br />
}<br />
} else {<br />
# repeat message, parse accordingly<br />
# first, clone the last entry<br />
for ($loop=0; $loop&lt;12; $loop++) {<br />
$log[$counter][$loop] = $log[($counter-1)][$loop];<br />
}<br />
# then replace the count and timestamp portions with current<br />
$log[$counter][0] = $templine[7];<br />
$log[$counter][1] = "$templine[0] $templine[1] $templine[2]";<br />
}<br />
$counter ++;<br />
}<br />
close FH;<br />
<br />
###### Now let's print the results<br />
<br />
&printresults;<br />
<br />
###### Okay, we're done<br />
exit;<br />
<br />
##############################################################################<br />
####################### ##<br />
####################### Subroutines follow ##<br />
####################### ##<br />
##############################################################################<br />
<br />
sub printresults {<br />
<br />
# set HTML formatting variables<br />
my $headercellbegin = '&lt;td align="center">&lt;font color="#FFFFFF">&lt;b>';<br />
my $headercellend = "&lt;/b>&lt;/font>&lt;/td>\n";<br />
my $bodycellbegin = '&lt;td>&lt;font face="Arial, Helvetica" size="1">';<br />
my $bodycellend = "&lt;/font>&lt;/td>\n";<br />
<br />
<br />
# open page for printing as HTML<br />
print "Content-type: text/html\n\n";<br />
print "&lt;html>\n";<br />
print "&lt;head>&lt;/head>\n";<br />
print "&lt;body>\n";<br />
<br />
<br />
# if spec'ed, read /etc/services into a hash for fast lookups<br />
if ($service_lookups) {<br />
open FH, "/etc/services";<br />
foreach (&lt;FH>) {<br />
my @servtemp = split (/\s+/, $_);<br />
my @portproto = split ('/', $servtemp[1]);<br />
if ($portproto[1] eq 'tcp') {$portproto[1] = 'TCP';}<br />
if ($portproto[1] eq 'udp') {$portproto[1] = 'UDP';}<br />
# assign text to hash index {port}{protocol}<br />
$service{$portproto[0]}{$portproto[1]} = $servtemp[0];<br />
}<br />
close FH;<br />
<br />
# if spec'ed, patch results from /etc/services with local overrides<br />
if ($service_overrides) {<br />
open FH, "$service_overrides";<br />
foreach (&lt;FH>) {<br />
my @servtemp = split (/\s+/, $_);<br />
my @portproto = split ('/', $servtemp[1]);<br />
if ($portproto[1] eq 'tcp') {$portproto[1] = 'TCP';}<br />
if ($portproto[1] eq 'udp') {$portproto[1] = 'UDP';}<br />
# assign text to hash index {port}{protocol}<br />
$service{$portproto[0]}{$portproto[1]} = $servtemp[0];<br />
}<br />
close FH;<br />
}<br />
}<br />
<br />
print "&lt;table border=1 cellpadding=5 cellspacing=0>\n";<br />
print "&lt;tr bgcolor='#000000'>\n";<br />
print $headercellbegin . '#' . $headercellend;<br />
print $headercellbegin . 'datestamp' . $headercellend;<br />
# print $headercellbegin . 'fwhost' . $headercellend;<br />
print $headercellbegin . 'rule' . $headercellend;<br />
print $headercellbegin . 'action' . $headercellend;<br />
print $headercellbegin . 'proto' . $headercellend;<br />
print $headercellbegin . 'shost' . $headercellend;<br />
if ($host_lookups) {print $headercellbegin . 'shostname' . $headercellend;}<br />
print $headercellbegin . 'sport' . $headercellend;<br />
print $headercellbegin . 'dhost' . $headercellend;<br />
print $headercellbegin . 'dport' . $headercellend;<br />
print $headercellbegin . 'dir' . $headercellend;<br />
print $headercellbegin . 'iface' . $headercellend;<br />
if ($host_lookups) {print $headercellbegin . 'servicename' . $headercellend;}<br />
<br />
for ($loop = $counter - 1; $loop > -1; $loop--) {<br />
unless ($log[$loop][6] eq '') {<br />
print "&lt;tr>\n";<br />
<br />
for ($element=0; $element&lt;12; $element++) {<br />
unless ($element eq 2) {print $bodycellbegin . $log[$loop][$element] . $bodycellend;}<br />
if ($host_lookups * ($element eq 6)) {<br />
my $hostname = `$dig_cmd $log[$loop][6] $dig_opts`;<br />
if (($hostname =~ m/\&lt;\&lt;\>\>/) + ($hostname eq '')) {$hostname = '&nbsp;';}<br />
print $bodycellbegin . $hostname . $bodycellend;<br />
}<br />
}<br />
if ($service_lookups) {print $bodycellbegin . $service{$log[$loop][9]}{$log[$loop][5]} . '&nbsp;' . $bodycellend;}<br />
print "&lt;/tr>\n";<br />
}<br />
}<br />
print "&lt;/table>\n";<br />
print "&lt;/body>\n";<br />
print "&lt;/html>\n";<br />
}<br />
<br />
<br />
################################################################<br />
################################################################<br />
<br />
sub ReadParse {<br />
local (*in) = @_ if @_;<br />
local ($i, $key, $val);<br />
<br />
# Read in text<br />
if ($ENV{'REQUEST_METHOD'} eq "GET") {<br />
$in = $ENV{'QUERY_STRING'};<br />
} elsif ($ENV{'REQUEST_METHOD'} eq "POST") {<br />
read(STDIN,$in,$ENV{'CONTENT_LENGTH'});<br />
}<br />
<br />
@in = split(/[&;]/,$in);<br />
<br />
foreach $i (0 .. $#in) {<br />
# Convert plus's to spaces<br />
$in[$i] =~ s/\+/ /g;<br />
<br />
# Split into key and value.<br />
($key, $val) = split(/=/,$in[$i],2); # splits on the first =.<br />
<br />
# Convert %XX from hex numbers to alphanumeric<br />
$key =~ s/%(..)/pack("c",hex($1))/ge;<br />
$val =~ s/%(..)/pack("c",hex($1))/ge;<br />
<br />
# Associate key and value<br />
$in{$key} .= "\0" if (defined($in{$key})); # \0 is the multiple separator<br />
$in{$key} .= $val;<br />
<br />
}<br />
<br />
return scalar(@in);<br />
}</nowiki><br />
<br />
[[Category:Common Tasks]]<br />
[[Category: Securing FreeBSD]]<br />
[[Category:Firewall]]</div>Jimbohttp://freebsdwiki.net/index.php/Firewall,_ConfiguringFirewall, Configuring2012-08-25T22:09:01Z<p>Jimbo: </p>
<hr />
<div>==Don't need NAT? don't rebuild the kernel!==<br />
The system will dynamically load the kernel module when the rc.conf statement firewall_enable="YES" is used. You do not need to compile IPFW into the FreeBSD kernel unless you want NAT function enabled. You'll still need a ruleset to deal with the traffic your machine gets, of course.<br />
<br />
<br />
== Building an [[ipfw]]-enabled kernel ==<br />
<br />
You're going to need to rebuild your kernel with the appropriate options for the firewall you want to build. We've already got an [[Custom Kernel|article]] on building a custom kernel, but to start you off, here are some kernel options you'll almost certainly want and need:<br />
<br />
options IPFIREWALL # you need this to enable ipfw<br />
options IPFIREWALL_VERBOSE # you need this to enable ipfw logging<br />
options IPFIREWALL_VERBOSE_LIMIT=10 # limit to 10 identical log entries<br />
options IPDIVERT # enable NAT<br />
<br />
It would be advisable to check out the NOTES files for your particular BSD version and architecture to check out other interesting kernel packet-filtering capabilities that you might or might not want to consider. For example, some kernels support IPSEC (or FAST_IPSEC) security, TCP_DROP_SYNFIN (to defeat FIN scanning), IPSTEALTH (for "invisible" firewalls that don't show up in traceroutes)... but it varies by both BSD version and architecture, so check [[ /usr/src/sys/conf/NOTES]] for general options and [[ /usr/src/sys/(arch)/conf/NOTES]] for hardware-specific options.<br />
<br />
== Sample [[ipfw]] firewall ruleset ==<br />
<br />
This ruleset sets up a firewall on a "bastion" server that both runs publicly accessible services and acts as a NAT-enabled firewall for a protected network running behind it. <br />
<br />
'''ipfw''' rulesets are shell scripts that can be run directly from the command line (assuming you have an ipfw-enabled kernel loaded) - but remember, if you're running this on a [[default deny]] system, you will '''lose network connectivity''' on execution of the very first line of this script - meaning that you CANNOT run the script from a remote shell session, or it will stop running before it ever gets past '''deny all from any to any'''.<br />
<br />
So if you need to restart a firewall remotely, you'll have to use some minor trickery - like scheduling it with the [[at]] scheduler. THAT will work, since jobs started from [[at]] don't depend on network connectivity to continue running. However, if you're running untested modifications, you'll probably want to schedule ANOTHER job with [[at]] for 5 minutes later to pull your firewall back to a "known accessible" configuration, just in case there's a really bad bug in your new rules that will deny you access. NOT leaving yourself a scheduled "oops" to bring you back to a known accessible condition, just in case, could end up costing you a very long drive out to wherever your server is.<br />
<br />
With no further ado, here's the sample ipfw ruleset script.<br />
<br />
#!/bin/sh<br />
<br />
#Quietly flush out rules<br />
/sbin/ipfw -q -f flush<br />
<br />
#Set command prefix (add "-q" option after development to turn on quiet mode)<br />
cmd="/sbin/ipfw add"<br />
<br />
# set outside and inside network interfaces<br />
oif="xl0"<br />
iif="ed0"<br />
<br />
# set private IP of this server and the netmask of the whole LAN side<br />
server="192.168.0.1"<br />
inside="192.168.0.0/24"<br />
<br />
######Localhost stuff<br />
#<br />
#allow the computer to talk to itself<br />
$cmd 00080 allow ip from any to any via lo0<br />
<br />
#don't let anything from the "outside" talk to localhost<br />
$cmd 00081 deny ip from any to 127.0.0.0/8<br />
<br />
#don't let the computer talk other computers as localhost<br />
$cmd 00082 deny log ip from 127.0.0.0/8 to any<br />
#<br />
#######<br />
<br />
####### DHCP stuff<br />
#<br />
# you need this to be able to renew your DHCP lease from your ISP<br />
$cmd 00083 allow udp from any 67 to any 68 in recv rl0<br />
#<br />
#####<br />
<br />
######### deny-and-log bogus packets by tcpflags<br />
#<br />
# XMAS tree<br />
$cmd 00084 deny log tcp from any to any in tcpflags fin,psh,urg recv $oif<br />
# NULL scan (no flag set at all)<br />
$cmd 00085 deny log tcp from any to any in tcpflags !fin,!syn,!rst,!psh,!ack,!urg recv $oif<br />
# SYN flood (SYN,FIN)<br />
$cmd 00086 deny log tcp from any to any in tcpflags syn,fin recv $oif<br />
# Stealth FIN scan (FIN,RST)<br />
$cmd 00087 deny log tcp from any to any in tcpflags fin,rst recv $oif<br />
# forced packet routing<br />
$cmd 00089 deny log ip from any to any in ipoptions ssrr,lsrr,rr,ts recv $oif<br />
#<br />
#######<br />
<br />
<br />
<br />
######### Things served via this machine directly <br />
######### Any services on this machine should be placed here,<br />
######### before the NAT Divert rule<br />
#<br />
#HTTP<br />
$cmd 00500 allow tcp from any to any 80 in via $oif<br />
#SSH<br />
$cmd 00510 allow tcp from any to any 22 in via $oif<br />
#FTP<br />
$cmd 00570 allow ip from any to any 20 in via $oif<br />
$cmd 00571 allow ip from any to any 21 in via $oif<br />
$cmd 00572 allow tcp from any 21 to any out via $oif<br />
#<br />
####<br />
<br />
<br />
#####NATD stuff<br />
<br />
#natd Divert rule<br />
$cmd 01000 divert natd all from any to any via $oif<br />
<br />
######<br />
<br />
<br />
####All connections originating from my network are allowed<br />
<br />
# check to see if a dynamic rule has been created that matches this packet<br />
$cmd 01100 check-state<br />
# let everything on your internal network talk to the firewall<br />
$cmd 01101 allow all from any to any via $iif keep-state <br />
# setup a dynamic rule for any connections being started from inside<br />
$cmd 01102 allow all from any to any out via $oif keep-state <br />
# deny ACK packets that did not match the dynamic rule table - do not log, too many false positives<br />
$cmd 01103 deny tcp from any to any established in via $oif <br />
#deny fragments as bogus packets<br />
$cmd 01104 deny log all from any to any frag in via $oif <br />
#####<br />
<br />
<br />
####### ICMP stuff<br />
<br />
#allow path-mtu in both directions<br />
$cmd 01200 allow icmp from any to any icmptypes 3<br />
<br />
#allow source quench in and out<br />
$cmd 01201 allow icmp from any to any icmptypes 4<br />
<br />
#allow outbound traceroutes<br />
$cmd 01204 allow icmp from any to any icmptypes 11 in<br />
<br />
#allow outbound pings and incoming ping responses<br />
$cmd 01202 allow icmp from any to any icmptypes 8 out<br />
$cmd 01203 allow icmp from any to any icmptypes 0 in<br />
<br />
########<br />
<br />
<br />
<br />
##### This section is for exposing services to the internet from the LAN<br />
##### It is placed AFTER the NATD Divert rule, so these services can be<br />
##### diverted in /etc/natd.conf<br />
<br />
#VNC - allow it, but log connection attempts (though DON'T log traffic for established sessions)<br />
$cmd 01550 allow log tcp from any to any 5900 in setup<br />
$cmd 01551 allow tcp from any to any 5900 in<br />
#KAZAA<br />
$cmd 01580 allow ip from any to $inside 1214 in via $oif<br />
#SOULSEEK<br />
$cmd 01590 allow ip from any to $inside 2234 in via $oif<br />
$cmd 01591 allow ip from any to $inside 5534 in via $oif<br />
#EMULE<br />
$cmd 01600 allow tcp from any to $inside 4662 in via $oif<br />
$cmd 01601 allow udp from any to $inside 4672 in via $oif<br />
#BITTORRENT<br />
$cmd 01610 allow ip from any to $inside 30000-40000 in via $oif<br />
<br />
####<br />
<br />
######## SOME THINGS ARE TOO NOISY TO LIVE<br />
######## In this section we deny things that would be denied anyway, but that we just<br />
######## don't want logged. Be careful with this - in general, you probably want to <br />
######## avoid putting anything in here that doesn't specify a known source address that<br />
######## is relatively trustworthy. You also want to be very careful about who knows<br />
######## what this section of your firewall configs looks like, because they can then<br />
######## use the info to craft probes and attacks they know you won't see or log.<br />
<br />
# Don't bother logging IGMP crap from the ISP<br />
$cmd 9004 deny igmp from 172.16.210.1 to any in via $oif<br />
<br />
# Don't bother logging DNS garbage inbound from the ISP's DNS boxes<br />
$cmd 9006 deny udp from 4.31.99.0/24\{100-103\} 53 to any dst-port 50000-65535 in via $oif<br />
<br />
#####<br />
<br />
######## Stealth scans of closed ports<br />
######## this section is to deny and log stealth scans that we can't really deny <br />
######## on open ports because doing so would disrupt legitimate services.<br />
<br />
# ACK scan (ACK,RST)<br />
$cmd 60000 deny log tcp from any to any in tcpflags ack,rst recv $oif<br />
<br />
#####<br />
<br />
#############<br />
############# DEFAULT RULE - deny it, and log it, 'cause we're secure like that.<br />
#############<br />
#<br />
$cmd 65000 deny log all from any to any<br />
<br />
== Sample /etc/natd.conf ==<br />
<br />
Our bastion firewall/server will also need to handle NAT duties for the boxes it's protecting on the LAN side. [[ /etc/natd.conf]] is the configuration file for natd, and will allow you to redirect ports from the public side to services on the LAN side, as well as handling standard NATting of connection requests from our protected network to the big bad Internet. Here's a sample [[ /etc/natd.conf]].<br />
<br />
(Note that for redirection of services to work, you need matching entries in your IPFW ruleset after the NAT Divert rule to allow those services inbound access as well as entries in this [[ /etc/natd.conf]]!)<br />
<br />
# "interface" should be the WAN interface<br />
interface xl0<br />
use_sockets yes<br />
same_ports yes<br />
# set "dynamic" if the WAN interface is controlled by DHCP<br />
dynamic yes<br />
<br />
#VNC<br />
redirect_port tcp 192.168.0.10:5900 5900<br />
#KAZAA<br />
redirect_port tcp 192.168.0.25:1214 1214<br />
#SOULSEEK<br />
redirect_port tcp 192.168.0.25:2234 2234<br />
redirect_port tcp 192.168.0.25:5534 5534<br />
#EMULE<br />
redirect_port tcp 192.168.0.25:4662 4662<br />
redirect_port udp 192.168.0.25:4672 4672<br />
#BITTORRENT<br />
redirect_port tcp 192.168.0.25:30000-40000 30000-40000<br />
<br />
== Sample /usr/local/etc/dhcpd.conf file ==<br />
<br />
We're also going to want our bastion firewall/server to deliver DHCP leases to the computers on the protected network. So after installing the dhcp daemon from the '''/usr/ports/net/isc-dhcp3''' port, you'll need to minimally configure it to actually deliver the leases to the clients. Here's a sample [[ /usr/local/etc/dhcpd.conf]] file:<br />
<br />
# dhcpd.conf<br />
#<br />
# Configuration file for ISC dhcpd<br />
#<br />
# option definitions common to all supported networks...<br />
option domain-name "yourdomain.local";<br />
option domain-name-servers 192.168.0.99;<br />
default-lease-time 604800;<br />
max-lease-time 2592000;<br />
<br />
ddns-update-style none;<br />
<br />
# If you have more than one subnet, list them seperately.<br />
subnet 192.168.0.0 netmask 255.255.255.0 {<br />
range 192.168.0.200 192.168.100.250;<br />
option routers 192.168.0.1;<br />
option broadcast-address 192.168.0.255;<br />
default-lease-time 4800;<br />
max-lease-time 7200;<br />
}<br />
<br />
# This would be for a second subnet, if you had one:<br />
# subnet 192.168.5.0 netmask 255.255.255.0 {<br />
# range 192.168.5.200 192.168.5.254;<br />
# option routers 192.168.5.1;<br />
# option broadcast-address 192.168.5.255;<br />
# default-lease-time 4800;<br />
# max-lease-time 7200;<br />
# }<br />
<br />
# EOF<br />
<br />
see also: [[Firewall, Monitoring]]<br />
<br />
<br />
== Helpful External Links ==<br />
<br />
http://www.freebsddiary.org/ipfw.php<br />
<br />
http://www.onlamp.com/pub/a/bsd/2001/05/09/FreeBSD_Basics.html<br />
<br />
http://blogs.geekdojo.net/andy/articles/1807.aspx VERY VERY helpful <br />
<br />
http://www.acme.com/firewall.html more with the SUPER helpfulness<br />
<br />
http://www.daniweb.com/tutorials/2949.html for getting dhcpd running<br />
<br />
[[Category:Common Tasks]]<br />
[[Category:FreeBSD for Servers]]<br />
[[Category:Securing FreeBSD]]<br />
[[Category:Firewall]]</div>Jimbohttp://freebsdwiki.net/index.php/Category:FirewallCategory:Firewall2012-08-25T22:06:51Z<p>Jimbo: </p>
<hr />
<div>A '''firewall''' is a [[gateway]] device which sits between networks and examines the traffic wanting to pass through it, and makes decisions about whether to allow, deny, log, [[NAT]], and/or otherwise fiddle with that traffic on a packet-by-packet basis by consulting a ruleset it's been programmed with.<br />
<br />
The main purpose of most firewalls is to protect an internal network from malicious traffic inbound from the outside network(s), but they can also be used to monitor and/or control outbound traffic. In particular, in work-related environments it can be useful to deny outbound traffic on ports used for non-work-related peer-to-peer file-sharing networks; and to deny and log outbound traffic that is characteristic of malware-related activity.<br />
<br />
Under FreeBSD, three kernel firewalls are available; [[ipfw]] (FreeBSD-based), [[pf]] (OpenBSD-originated, ported to FreeBSD), and [[ipf]] (OS-agnostic). [[ipfw]] and [[ipf]] will work as [[modules]] but if you're going to be running them at all, you'll probably want to recompile your kernel for static support -- see [[Firewall, Configuring]], below.<br />
<br />
If you want your article to appear in this category, append <nowiki>[[Category:Firewall]]</nowiki> to its end.</div>Jimbohttp://freebsdwiki.net/index.php/SmoothWallSmoothWall2012-08-25T22:06:29Z<p>Jimbo: Reverted edits by 173.88.199.104 (talk) to last revision by DrModiford</p>
<hr />
<div>SmoothWall is an out-of-the-box firewall solution from SmoothWall Ltd., a UK based company. While not strictly FreeBSD related, it being based on GNU/Linux, it is an open source and freely available alternative for those not confident enough to use FreeBSD's in-built firewall solutions. It requires an IBM compatible i386 (or better) computer in which to install - '''it will wipe the entire drive''' - ensure the computer in question is no longer required and can be dedicated to running SmoothWall.<br />
<br />
== Overview ==<br />
<br />
SmoothWall is a firewall that works well for a small home LAN, through to small offices right up to corporate-scale environments. The company behind the product offer professional versions of the free offering that provide advanced features. This allows for the free version, known as SmoothWall Express, to continue to be available at no cost. This is similar to dual-licensing schemes used by the companies behind PostgreSQL and MySQL and other open source solutions.<br />
<br />
Despite being free the product boasts features found in high-end firewall routers from Netgear or D-Link and has regular security fixes available.<br />
<br />
== Features ==<br />
<br />
SmoothWall has a great list of features that makes it a serious contender for even the most advanced firewall router devices on the market. It can be thought of as a poor-mans equivalent of the commercially available CheckPoint Firewall system in that it is an operating system based firewall that runs on dedicated physical hardware.<br />
<br />
=== Key Features ===<br />
<br />
Key features (as of current release version 3.0) running through the menu options in order:<br />
<br />
* About<br />
** About Your SmoothWall - Active service status of your Smoothie;<br />
** Advanced Status - Pertinent information about your Smoothie, current configuration and resource usage;<br />
** Traffic Graphs - Statistical graphs based upon traffic usage across your SmoothWall's network interfaces;<br />
* Services<br />
** Web Proxy - Configure and enable your SmoothWall's integrated caching web proxy service;<br />
** DHCP - Configure and enable your SmoothWall's DHCP service, to automatically allocate LAN IP addresses to your network clients;<br />
** Dynamic DNS - Especially suited when your ISP assigned you a different IP address every time you connect, you can configure your SmoothWall to manage and update your dynamic DNS names from several popular services;<br />
** Intrusion Detection System (IDS) - Enable the Snort IDS service to detect potential security breach attempts from outside your network. Note that Snort does not prevent these attempts — your port forwarding and access rules are used to allow and deny inbound access from the outside;<br />
** Remote Access - Enable Secure Shell access to your SmoothWall, and restrict access based upon referral URL to ignore external links to your SmoothWall;<br />
** Time settings - Change timezone, manually set the time and date, and configure time syncronisation;<br />
* Networking<br />
** Port Forwarding - Forward ports from your external IP address to ports on machines inside your LAN or DMZ;<br />
** External Service Access - Allow access to admin services running on the SmoothWall to external hosts;<br />
** DMZ Pinholes - Enable access from a host on your DMZ to a port on a host on your LAN;<br />
** PPP Settings - Configure username, password and other details for up to five PPP, PPPoA or PPPoE connections;<br />
** IP block configuration - Add blocking rules to prevent access from specified IP addresses or networks;<br />
** Advanced networking features - Configure ICMP settings, and other advanced features;<br />
* VPN<br />
** VPN Control - Control and manage your VPN connections;<br />
** VPN Connections - Create connections to other SmoothWalls or IPSec-compliant hosts which have static IP addresses;<br />
* Logs<br />
** Log Viewer - Check activity logs for services operating on your SmoothWall, such as DHCP, IPSec, updates and core kernel activity;<br />
** Web Proxy Log Viewer - Check logs for the web proxy service;<br />
** Firewall Log Viewer - Check logs for attempted access to your network from outside hosts. Connections listed here have been blocked;<br />
** IDS Log Viewer - Check logs for potentially malicious attempted access to your network from outside hosts. Connections listed here have not necessarily been blocked — use the Firewall Log Viewer to confirm blocked access;<br />
* Tools<br />
** IP Information - Perform a 'whois' lookup on an ip address or domain name;<br />
** IP Tools - Perform 'ping' and 'traceroute' network diagnostics;<br />
** Secure Shell - Connect to your SmoothWall using a Java SSH applet (requires SSH to be enabled);<br />
* Maintenance<br />
** Updates - See the latest updates and fixes available for your SmoothWall, and an installation history of updates previously applied;<br />
** Modem Configuration - Apply specific AT string settings for your PSTN modem or ISDN TA;<br />
** USB ADSL Firmware Upload - Upload firmware to enable use of an Alcatel/Thomson Speedtouch Home USB ADSL modem, nicknamed the 'frog' or 'stingray'. Download the 'Speedtouch USB Firmware' tarball, unpack it, and upload the mgmt.o file using this form;<br />
** Change Passwords - Change passwords for the 'admin' and 'dial' management interface users. This does not affect access by SSH;<br />
** Backup - Use this page to create a backup floppy disk or floppy disk image file;<br />
<br />
=== Network Ports ===<br />
<br />
SmoothWall utilises a scheme of colours to refer to the network interfaces as follows:<br />
<br />
* Red - The internet facing connection, often referred to as the 'dirty side';<br />
* Green - The internal facing connection, often referred to as the 'clean side';<br />
* Orange - An in-between connection, commonly referred to as the 'demilitarized zone' (DMZ);<br />
* Purple - A dedicated port for wireless connectivity;<br />
<br />
The red interface on SmoothWall can be an ethernet connection to a leased line, an ISDN connection, a USB ADSL (broadband) modem or even a humble dial-up modem!<br />
<br />
The green interface is an ethernet network connection that serves the local LAN and typically connects to a hub or switch to distribute the internet connection to other LAN systems.<br />
<br />
The orange interface is an ethernet network connection that is neither on the red or the green networks This is typically where internet facing servers connect, such as a web server and/or email server. The green network can access the orange network servers freely but not the other way around (unless explicitly configured by DMZ pinholes). In much the same way the orange network servers can freely access the red internet but not the other way around (unless explicitly configured by port forwarding).<br />
<br />
The purple interface is an ethernet network connection that is intended to link to a wireless access point. While an access point can be encrypted with WEP, WPA or equivalents the use of the purple network allows added security at the firewall level. ''This feature was introduced with the 3.0 release'''.<br />
<br />
== Links ==<br />
<br />
The freely available SmoothWall Express (currently release version 3.0) is available from the [http://www.smoothwall.org/get/ www.smoowall.org] website.<br />
<br />
The commercial entity SmoothWall Limited is available from [http://www.smoothwall.net/ www.smoothwall.net].<br />
<br />
== See Also (Alternatives) ==<br />
<br />
There are a few alternatives worth mentioning:<br />
<br />
ClarkConnect - this is a GNU/Linux system based on Red Hat and similar to SmoothWall has a freely available version alongside corporate licensed versions.<br />
<br />
IPCop - this was a forked-version of SmoothWall and as such is similar in operation though the authors took the system in a different direction. It had a 'blue' network connection for wireless long before SmoothWall introduced the 'purple' network connection for wireless.<br />
[http://www.ipcop.org www.ipcop.org]<br />
<br />
m0n0wall - this is a stripped-down FreeBSD based firewall that uses PHP for the back-end control and configuration.<br />
[http://m0n0.ch/wall/ m0n0.ch/wall]<br />
<br />
Shorewall - this is a GNU/Linux system that uses the in-built iptable/ipchains rule set found on this operating system.<br />
[http://shorewall.net/ shorewall.net]<br />
<br />
Of course, there are always the in-built firewalls available on FreeBSD itself [[Firewall]]!<br />
<br />
[[Category:Firewall]]</div>Jimbohttp://freebsdwiki.net/index.php/Partitioning_Tips_and_TricksPartitioning Tips and Tricks2012-08-25T22:06:09Z<p>Jimbo: Reverted edits by 173.88.199.104 (talk) to last revision by Jimbo</p>
<hr />
<div>You may find [[Hard Disk Partition Sizes]] useful if you are setting up partitions for the first time.<br />
<br />
==Make yourself a tiny little partition for /mnt==<br />
If you plan to work with removable read-write filesystems - USB drives, IDE or SCSI removables, whatever - make yourself a teeny tiny (like 5 or 10 MB or less) partition for /mnt, and mount the devices to /mnt/removable or /mnt/usbdrive or what have you. That way if a script or a command you run tries to copy a few gigs worth of data and you DON'T have your removable device properly mounted, it will fill your little throwaway /mnt partition that you don't really need (and do it very quickly), instead of you accidentally filling your root partition, which can cause system instabilities.<br />
<br />
==Use soft links to your advantage!==<br />
Don't forget that you can use [[ln]] to do really nifty things with your drives and partitions. For example if you've made a too small /usr partition and a very large /data partition, you might want to move the ports tree - which can occupy several gigs of space if you build lots of ports and aren't meticulous about cleaning out old distfiles and work directories - into the larger /data partition. But instead of trying to laboriously fix the entire system so that it looks in /data/ports instead of /usr/ports, what you can do instead is '''mv /usr/ports /data/''' and then '''ln -s /data/ports /usr/ports''' - now it ''looks'' and ''works'' as though the ports tree is still in the default location, but in fact it's operating from the bigger partition!<br />
<br />
Another common use for this is /var/db on servers with large databases. By default [[mysql]] places databases in /var/db, which is normally a very small partition (256MB or so) - and can be overwritten disturbingly quickly with apache logs and mailserver logs and the like, not to mention the databases themselves. Rather than recompiling or reconfiguring the database server itself to look for its database in a different location, you can simply move the databases to a different partition and soft link to them, just as was described for the ports tree in the paragraph above. Kill the database server, '''mv /var/db /data/db && ln -s /data/db /var/db''' and restart the server with no conf changes necessary, and you're in business!<br />
<br />
==Multiple Disks? Multiple /swap==<br />
If you've got two or more disks, you'll speed up performance on them by creating swap partitions on both of them -- no more moving data through the system bus to page files from disk 1 to your swap partition on disk 0. Some folks recommend that swap always be the first slice on the disk (even before / or any other partitions) because it's supposed to increase read/write times for stuff in swap; I've never noticed any real difference when I've done this, but if you have a lot of read/write-intensive operations (big databases, for e.g.,) you may want to consider this.<br />
<br />
NOTE: as always, the ''best'' way to speed up swap is not to need it in the first place - if you've got heavy swap partition activity, and you can possibly afford to do it, add more RAM. No matter ''what'' you do with your swap partition(s), accessing them is always going to be an order of magnitude or three slower than staying in RAM.<br />
<br />
==Getting Hard Disk Information==<br />
Sometimes you need information about the model or manufacturing numbers of drives that are in a running system. If the hard disk supports SMART (most do), you can use the smartctl utility (available from the sysutils/smartmontools [[ports tree | port]]) to extract the model numbers. Running '''smartctl -i /dev/ad4''' as root on my system gives output like this:<br />
=== START OF INFORMATION SECTION ===<br />
Device Model: WDC WD2500JB-00EVA0<br />
Serial Number: WD-WCAEH1028140<br />
Firmware Version: 15.05R15<br />
Device is: In smartctl database [for details use: -P show]<br />
ATA Version is: 6<br />
ATA Standard is: Exact ATA specification draft version not indicated<br />
Local Time is: Thu Dec 22 10:48:33 2005 CST<br />
SMART support is: Available - device has SMART capability.<br />
SMART support is: Enabled<br />
<br />
[[Category:New_User_Tips_and_FAQs]] [[Category:Common Tasks]]<br />
[[Category:FreeBSD for Servers]]</div>Jimbohttp://freebsdwiki.net/index.php/Hard_Disk_Partition_SizesHard Disk Partition Sizes2012-08-25T22:05:59Z<p>Jimbo: </p>
<hr />
<div>==Official Information and Terms==<br />
Before we get started, I am acting under the impression that the reader is a relative newbie to the world of FreeBSD, and is attempting to figure out how to partition their disks for the first time. I also assume that the reader is aware of the official FreeBSD documentation related to installing located here: [http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/install.html The FreeBSD Handbook Install Section]. More aware users will have discovered the partitioning information available under [http://www.freebsd.org/cgi/man.cgi?query=tuning&format=html man tuning] under FreeBSD 6.0 . By the existence of this page, however, you have also realized that some tweaking to both the default setup and the information in tuning is necessary for many installations.<br />
<br />
It is worth repeating that FreeBSD looks at hard disk partitions in a slightly different way from windows and linux. When I refer to partitions in the following sections, I am refering to FreeBSD style partitions, which are a bit different from what you may be used to under linux or Windows. To make a long story short, FreeBSD can hold many partitions inside of a single slice (a FreeBSD slice = a windows or linux partition). This frees FreeBSD from being limited to a rather inconvenient number of 4 or so partitions. Read the handbook carefully for more details<br />
<br />
==The Default Install==<br />
As of FreeBSD 6.0, sysinstall will create partitions sized approximately as follows by default:<br />
<br />
/ 128MB<br />
SWAP ''two times the system RAM''<br />
/var 256MB<br />
/tmp 256MB<br />
/usr ''remainder of the disk''<br />
<br />
Many of these partitions are entirely too small, and they are not sized with any thought regarding the usage of the machine. There are a few basic reasons to make a separate partition:<br />
#to nicely size a partition for a weird backup scheme that cannot handle unusually large backup dumps.<br />
#to protect the space needed by something (particularly the base system) from being stepped on by other programs<br />
#to limit particularly hungry programs from stepping on the space of everything else.<br />
Some thought about what you are trying to protect and what you are trying to limit is in order for configuring a system.<br />
<br />
==One Big Partition==<br />
The default install contrasts strongly with a fairly popular partitioning scheme for a system for an individual user. (NOTE: as of Release 9.0 sysinstall has been replaced with bsdinstall, and the default partition in now a single partition.)<br />
<br />
SWAP ''two times the system RAM''<br />
/ ''remainder of the disk''<br />
<br />
Although this will ''work'', this layout should ''never'' be used on an important system, for two major reasons:<br />
*In case of a serious system failure (repeated reboots), the entire drive will need to have it's file system checked with [[fsck]] on every reboot. The core systems of FreeBSD do not require very much disk space. Sensible partitioning would allow you to only check critical partitions, and put off the rest of the checks until the system is stable. This can be the difference between 2 minutes per reboot-with-fsck and '''thirty''' minutes per reboot-with-fsck on larger drives! (Note: this is not an issue with ZFS, since ZFS does not require fscks).<br />
<br />
*One of the primary reasons to separate things out, is to prevent one partition from filling up all the space and making other things stop working because they run out of space.<br />
<br />
==The SWAP partition==<br />
This one is fairly easy. The ''twice the amount of system RAM'' rule of thumb is a good one. If you have multiple hard disks on the system, [http://www.freebsd.org/cgi/man.cgi?query=tuning&apropos=0&sektion=0&manpath=FreeBSD+6.0-RELEASE+and+Ports&format=html man tuning] and [[Partitioning Tips and Tricks#Multiple Disks? Multiple /swap]] have some good suggestions.<br />
<br />
==The /tmp partition==<br />
It is extremely common for this partition to be undersized. This partition is used in building ports, and several programs will keep fairly large temporary files here. You want to make it a separate partition:<br />
*To protect the system from either a very large port compile (such as the larger windowmanagers or an X graphical interface system)<br />
*To prevent a run-away process that is simply filling the disk with as much data as possible from infringing on your / filespace.<br />
*To minimize the probability that the often-accessed /tmp directory will cause excessive file corruption on your / partition in the event of a crash.<br />
The danger of making this partition too small is that you will cause yourself unnecessary grief when you want to build a large package or when a program you are running needs alot of temporary space (such as a video editor).<br />
<br />
If you are not installing a graphical system and are unlikely to be editing large files, a fairly small tmp should work fine. Even compiling the larger ports should work inside of 128MB-256MB of tmp. If you will be editing either large numbers of image files or video files on the system (or other large files), a large sized tmp partition does seem more reasonable. A bit more than two times the largest file size you are likely to be editing would seem to be a reasonable limit.<br />
<br />
Another consideration for /tmp size is whether the system will be used for writing a CD or DVD. If so, /tmp needs to be sized to hold the interim file created, which can be just under 10GB for a dual-layer DVD.<br />
<br />
==The /var partition==<br />
var also depends highly on your intended use of the machine. Email, logs, the default [[mysql]] databases, another tmp directory, and print spooler information are all held in subdirectories of this partition. You may want to separate this off to prevent logs or emails from overrunning the system. If you plan to run a system with large mysql databases (such as a major mysql-backed forum or wiki site), you may want to consider replacing the /var/mysql directory with a [[soft links|soft link]] to a mysql directory on another, larger partition.<br />
<br />
===The /var/tmp directory===<br />
The /var/tmp directory can be deleted, and replaced with a [[soft links|soft link]] to the /tmp partition (or vice versa). This can be done with either '''ln -s /tmp /var/tmp''' or '''ln -s /var/tmp /tmp''' as root. This is recomended since there is essentially no difference between /var/tmp and /tmp on modern systems, but some programs use one instead of the other.<br />
<br />
==The /usr partition==<br />
The /usr partition contains a few major sections. There are a few approaches to this section. One is to give it it's own largish partition. Second - and '''absolutely not recommended''' - is to lump it into the main / partition (and either move the ports tree or watch its size carefully). Third is to split off several sections either into their own partitions or to symlink them from the / partition to a larger partition. Tuning recomends up to 3Gigs for /usr if you are going to have X installed with source, but I personally feel this would be a little bit limiting. 5-10 gigs seems more reasonable if you have the room.<br />
===The /usr/src/ directory===<br />
This contains the source code for the operating system, this is needed if you want to do a source update of the operating system via [[cvsup]] at some point. This really doesn't need its own partition, leaving it in /usr is fine.<br />
===The /usr/ports directory===<br />
By default /usr/ports contains the [[ports]] collection. /usr/ports/distfiles, which contains the packaged ports downloads, can grow quite large on a system that has many ports installed. On the other hand, you can keep it under control manually by deleting things periodically. Most ports do some of their compilation and install work in their own directories, however, and this will require a bit of stretching room. You might consider symlinking this to a larger partition if you decide to keep a small, essentials-only /usr to speed reboots-with-fsck after system crashes.<br />
===The /usr/local directory===<br />
This contains most of the files related to installed ports, in addition to your personal configurations in /usr/local/etc. This will need to be roughly sized with whatever you are installing. It will be very large for an X system, but fairly small for a simple ftp server.<br />
<br />
==The /home or /data partition==<br />
Assuming this is not a firewall or similarly specialized machine. Users (even if it is only yourself) will likely log in and want to use files. This partition, not created by the default install, is often given most of the disk. This is particularly true for personal servers and personal machines, which are likely to keep most of their files in this partition.<br />
<br />
The default partitioning scheme follows the idea of creating a link from /home to /usr/home, and giving /usr most of the disk. The problem with this is that /usr is needed to bring a system up, and in a situation where you may have as much as 250gigs (or more) of space under /usr, it will take quite awhile to file system check before you can bring the system up to check it. Which is particularly bad if you're having consistent crashes. One way to deal with this is to give /usr and /home their own partitions -- if /home has its own slice, it will not be made a link to /usr/home during the install.<br />
<br />
==Other Information==<br />
See also [[Partitioning Tips and Tricks]].<br />
<br />
[[Category:New_User_Tips_and_FAQs]] [[Category:Common Tasks]]<br />
[[Category:FreeBSD for Servers]]</div>Jimbohttp://freebsdwiki.net/index.php/Hard_Disk_Partition_SizesHard Disk Partition Sizes2012-08-25T22:04:16Z<p>Jimbo: Reverted edits by 173.88.199.104 (talk) to last revision by Jimbo</p>
<hr />
<div>==Official Information and Terms==<br />
Before we get started, I am acting under the impression that the reader is a relative newbie to the world of FreeBSD, and is attempting to figure out how to partition their disks for the first time. I also assume that the reader is aware of the official FreeBSD documentation related to installing located here: [http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/install.html The FreeBSD Handbook Install Section]. More aware users will have discovered the partitioning information available under [http://www.freebsd.org/cgi/man.cgi?query=tuning&format=html man tuning] under FreeBSD 6.0 . By the existence of this page, however, you have also realized that some tweaking to both the default setup and the information in tuning is necessary for many installations.<br />
<br />
It is worth repeating that FreeBSD looks at hard disk partitions in a slightly different way from windows and linux. When I refer to partitions in the following sections, I am refering to FreeBSD style partitions, which are a bit different from what you may be used to under linux or Windows. To make a long story short, FreeBSD can hold many partitions inside of a single slice (a FreeBSD slice = a windows or linux partition). This frees FreeBSD from being limited to a rather inconvenient number of 4 or so partitions. Read the handbook carefully for more details<br />
<br />
==The Default Install==<br />
As of FreeBSD 6.0, sysinstall will create partitions sized approximately as follows by default:<br />
<br />
/ 128MB<br />
SWAP ''two times the system RAM''<br />
/var 256MB<br />
/tmp 256MB<br />
/usr ''remainder of the disk''<br />
<br />
Many of these partitions are entirely too small, and they are not sized with any thought regarding the usage of the machine. There are a few basic reasons to make a separate partition:<br />
#to nicely size a partition for a weird backup scheme that cannot handle unusually large backup dumps.<br />
#to protect the space needed by something (particularly the base system) from being stepped on by other programs<br />
#to limit particularly hungry programs from stepping on the space of everything else.<br />
Some thought about what you are trying to protect and what you are trying to limit is in order for configuring a system.<br />
<br />
==One Big Partition==<br />
The default install contrasts strongly with a fairly popular partitioning scheme for a system for an individual user:<br />
<br />
SWAP ''two times the system RAM''<br />
/ ''remainder of the disk''<br />
<br />
Although this will ''work'', this layout should ''never'' be used on an important system, for two major reasons:<br />
*In case of a serious system failure (repeated reboots), the entire drive will need to have it's file system checked with [[fsck]] on every reboot. The core systems of FreeBSD do not require very much disk space. Sensible partitioning would allow you to only check critical partitions, and put off the rest of the checks until the system is stable. This can be the difference between 2 minutes per reboot-with-fsck and '''thirty''' minutes per reboot-with-fsck on larger drives! (Note: this is not an issue with ZFS, since ZFS does not require fscks).<br />
<br />
*One of the primary reasons to separate things out, is to prevent one partition from filling up all the space and making other things stop working because they run out of space.<br />
<br />
==The SWAP partition==<br />
This one is fairly easy. The ''twice the amount of system RAM'' rule of thumb is a good one. If you have multiple hard disks on the system, [http://www.freebsd.org/cgi/man.cgi?query=tuning&apropos=0&sektion=0&manpath=FreeBSD+6.0-RELEASE+and+Ports&format=html man tuning] and [[Partitioning Tips and Tricks#Multiple Disks? Multiple /swap]] have some good suggestions.<br />
<br />
==The /tmp partition==<br />
It is extremely common for this partition to be undersized. This partition is used in building ports, and several programs will keep fairly large temporary files here. You want to make it a separate partition:<br />
*To protect the system from either a very large port compile (such as the larger windowmanagers or an X graphical interface system)<br />
*To prevent a run-away process that is simply filling the disk with as much data as possible from infringing on your / filespace.<br />
*To minimize the probability that the often-accessed /tmp directory will cause excessive file corruption on your / partition in the event of a crash.<br />
The danger of making this partition too small is that you will cause yourself unnecessary grief when you want to build a large package or when a program you are running needs alot of temporary space (such as a video editor).<br />
<br />
If you are not installing a graphical system and are unlikely to be editing large files, a fairly small tmp should work fine. Even compiling the larger ports should work inside of 128MB-256MB of tmp. If you will be editing either large numbers of image files or video files on the system (or other large files), a large sized tmp partition does seem more reasonable. A bit more than two times the largest file size you are likely to be editing would seem to be a reasonable limit.<br />
<br />
Another consideration for /tmp size is whether the system will be used for writing a CD or DVD. If so, /tmp needs to be sized to hold the interim file created, which can be just under 10GB for a dual-layer DVD.<br />
<br />
==The /var partition==<br />
var also depends highly on your intended use of the machine. Email, logs, the default [[mysql]] databases, another tmp directory, and print spooler information are all held in subdirectories of this partition. You may want to separate this off to prevent logs or emails from overrunning the system. If you plan to run a system with large mysql databases (such as a major mysql-backed forum or wiki site), you may want to consider replacing the /var/mysql directory with a [[soft links|soft link]] to a mysql directory on another, larger partition.<br />
<br />
===The /var/tmp directory===<br />
The /var/tmp directory can be deleted, and replaced with a [[soft links|soft link]] to the /tmp partition (or vice versa). This can be done with either '''ln -s /tmp /var/tmp''' or '''ln -s /var/tmp /tmp''' as root. This is recomended since there is essentially no difference between /var/tmp and /tmp on modern systems, but some programs use one instead of the other.<br />
<br />
==The /usr partition==<br />
The /usr partition contains a few major sections. There are a few approaches to this section. One is to give it it's own largish partition. Second - and '''absolutely not recommended''' - is to lump it into the main / partition (and either move the ports tree or watch its size carefully). Third is to split off several sections either into their own partitions or to symlink them from the / partition to a larger partition. Tuning recomends up to 3Gigs for /usr if you are going to have X installed with source, but I personally feel this would be a little bit limiting. 5-10 gigs seems more reasonable if you have the room.<br />
===The /usr/src/ directory===<br />
This contains the source code for the operating system, this is needed if you want to do a source update of the operating system via [[cvsup]] at some point. This really doesn't need its own partition, leaving it in /usr is fine.<br />
===The /usr/ports directory===<br />
By default /usr/ports contains the [[ports]] collection. /usr/ports/distfiles, which contains the packaged ports downloads, can grow quite large on a system that has many ports installed. On the other hand, you can keep it under control manually by deleting things periodically. Most ports do some of their compilation and install work in their own directories, however, and this will require a bit of stretching room. You might consider symlinking this to a larger partition if you decide to keep a small, essentials-only /usr to speed reboots-with-fsck after system crashes.<br />
===The /usr/local directory===<br />
This contains most of the files related to installed ports, in addition to your personal configurations in /usr/local/etc. This will need to be roughly sized with whatever you are installing. It will be very large for an X system, but fairly small for a simple ftp server.<br />
<br />
==The /home or /data partition==<br />
Assuming this is not a firewall or similarly specialized machine. Users (even if it is only yourself) will likely log in and want to use files. This partition, not created by the default install, is often given most of the disk. This is particularly true for personal servers and personal machines, which are likely to keep most of their files in this partition.<br />
<br />
The default partitioning scheme follows the idea of creating a link from /home to /usr/home, and giving /usr most of the disk. The problem with this is that /usr is needed to bring a system up, and in a situation where you may have as much as 250gigs (or more) of space under /usr, it will take quite awhile to file system check before you can bring the system up to check it. Which is particularly bad if you're having consistent crashes. One way to deal with this is to give /usr and /home their own partitions -- if /home has its own slice, it will not be made a link to /usr/home during the install.<br />
<br />
==Other Information==<br />
See also [[Partitioning Tips and Tricks]].<br />
<br />
[[Category:New_User_Tips_and_FAQs]] [[Category:Common Tasks]]<br />
[[Category:FreeBSD for Servers]]</div>Jimbohttp://freebsdwiki.net/index.php/MegarcMegarc2012-08-25T22:02:23Z<p>Jimbo: Reverted edits by 173.88.199.104 (talk) to last revision by Jimbo</p>
<hr />
<div>[[Category:Ports and Packages]] [[Category:RAID]]<br />
'''''{{PAGENAME}}''''' is a commandline utility that provides an interface to many of the configuration and reporting functions for LSI Logic's MegaRAID BIOS (http://www.lsilogic.com). <br />
<br />
==Megarc port for FreeBSD==<br />
The ''megarc'' utility ships as a binary, without any accompanying documentation, on the "Megaraid Universal Software Suite" CD which accompanies any boxed LSI Logic RAID storage adapter. It is also found in the FreeBSD ports collection.<br />
<br />
* On the CD that comes with the storage adapter, the utility is found in two places. It is part of a zipped bundle in <cd>:\SW_Components\Drivers\dr_freebsd_1.51.zip on our distribution. The zip file contents are as follows:<br />
<br />
<pre><br />
Length Date Time Name<br />
-------- ---- ---- ----<br />
130448 04-18-05 14:10 MegaRC 1.04.zip<br />
12953 10-08-04 16:05 amr_x86_64_ver1_51FreeBSD5.3.tgz<br />
153600 03-17-05 15:19 code.tar<br />
535 02-10-05 11:02 FreeBSDDriverUpdate.txt<br />
12774 10-12-04 19:38 amr_i386_ver_1_51_FreeBSD5.3.tgz<br />
-------- -------<br />
310310 5 files<br />
</pre><br />
<br />
* The utility is also found on the CD by itself, at "<cd>:\SW_Components\Utilities\ut_FreeBSD_MegaRC 1.04.zip".<br />
<br />
* It can be downloaded from LSI at http://www.lsi.com/DistributionSystem/AssetDocument/files/support/rsa/beta/drivers/dr_freebsd_1.51.zip<br />
<br />
* It can be also be installed from the [http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/megarc/ ports collection] at /usr/ports/sysutils/megarc. The port extracts the binary from the bundled dr_freebsd_*.zip Our example was installed from the ports collection on 6.1-PRERELEASE FreeBSD amd64<br />
<br />
<br />
<pre><br />
# file /usr/local/sbin/megarc<br />
/usr/local/sbin/megarc: ELF 32-bit LSB executable, Intel 80386,<br />
version 1 (FreeBSD), for FreeBSD 5.2.1, statically linked, stripped<br />
</pre><br />
<br />
==Documentation==<br />
The documentation for megarc is limited to the output of its ?/help functions. Since these [[RAID]] adapters are reasonably popular, and the commands are a bit scary and somewhat obscurely named, this page might prove helpful to someone even though it's not complete. <br />
<br />
Megarc must be run with sufficient privileges, or the adapter will not be found. "?" and "help" are not synonymous. ''?'' (mis-named "complete help") gives brief syntax hints. ''help'' gives a fuller description of what the command does, and its arguments and usage. <br />
<br />
* To see the commands available, as root type:<br /><code>megarc ?</code><br />
First Parameter should be :<br />
-AllAdpInfo <br />
... etc ...<br />
*To see a list of commands and syntax, type:<br /> <code>megarc help</code><br />
<pre><br />
-------------------------------------------------------------------------<br />
* Convention Used:<br />
[Cmd = The name of the utility]<br />
opt1|opt2|opt3 => Only one of these can be specified<br />
<br />
-------------------------------------------------------------------------<br />
Cmd ?: Gives complete help<br />
Cmd -functionality ?: functionality specific help<br />
Example:<br />
Cmd -ctlrInfo ? :help on -ctlrinfo option<br />
<br />
-------------------------------------------------------------------------<br />
Usage: Cmd -ctlrInfo -aX <br />
... etc ...<br />
</pre><br />
* '''Example:'''<br /> <code> megarc -ctlrInfo help </code><br />
<pre><br />
**********************************************************************<br />
<br />
usage :<br />
cmd -ctlrInfo -aX<br />
: Shows general adapter info of adapter<br />
**********************************************************************<br />
where :<br />
cmd : name of the utility<br />
-aX : adapter number X(max 12 adapters). X=0..11<br />
**********************************************************************<br />
</pre><br />
<br />
==Examples==<br />
For the examples below, we are using an LSILogic 150-6 x64 SATA RAID adapter on a 32-bit PCI slot - "adapter 0" on the system - with a RAID 5 volume consisting of five (5) physical SATA drives of 400GB each. The hot-spare belongs to target 00 but is being replaced at the time of this writing.<br />
<br />
Below are some brief descriptions of some of the commands, and some examples of output from a few of the information functions. These command-options are not case-sensitive.<br />
<br />
===megarc -dispCfg -a0 ===<br />
Display the configuration for adapter ''0''.<br />
<br />
<pre><br />
Logical Drive : 0( Adapter: 0 ): Status: OPTIMAL<br />
---------------------------------------------------<br />
SpanDepth :01 RaidLevel: 5 RdAhead : No Cache: DirectIo<br />
StripSz :064KB Stripes : 5 WrPolicy: WriteThru<br />
<br />
Logical Drive 0 : SpanLevel_0 Disks<br />
Chnl Target StartBlock Blocks Physical Target Status<br />
---- ------ ---------- ------ ----------------------<br />
0 01 0x00000000 0x2e936800 ONLINE<br />
0 02 0x00000000 0x2e936800 ONLINE<br />
0 03 0x00000000 0x2e936800 ONLINE<br />
0 04 0x00000000 0x2e936800 ONLINE<br />
0 05 0x00000000 0x2e936800 ONLINE<br />
</pre><br />
<br />
===megarc -LogPhysInfo -a0 ===<br />
Display the physical drive information for each of the logical drives on adapter ''0''.<br />
<br />
<pre><br />
Logical drive 0: RaidLevel 5<br />
<br />
Physical Drive Information<br />
Channel 0<br />
381549MB drive ID 1<br />
CoerSZ: 781412352(Sectors) 381549(MB) RawSZ: 781422255(Sectors)<br />
381549MB drive ID 2<br />
CoerSZ: 781412352(Sectors) 381549(MB) RawSZ: 781422255(Sectors)<br />
381549MB drive ID 3<br />
CoerSZ: 781412352(Sectors) 381549(MB) RawSZ: 781422255(Sectors)<br />
381549MB drive ID 4<br />
CoerSZ: 781412352(Sectors) 381549(MB) RawSZ: 781422255(Sectors)<br />
381549MB drive ID 5<br />
CoerSZ: 781412352(Sectors) 381549(MB) RawSZ: 781422255(Sectors)<br />
<br />
</pre><br />
<br />
===megarc -ScfgAndParm|-DfcfgAndParm|-RcfgAndParm -fFileName -a0 ===<br />
Save, Display, or Restore the configuration and parameters for adapter ''0'', in ''FileName''. ''FileName'' stores the same output provided by -dispCfg in a binary format, making it possible to directly load the stored configuration from the file.<br />
<br />
===megarc -physOn pd[c0:t0,c1:t1....] -a0===<br />
<br />
Set the state of the designated drive(s) to ''Online''. ''pd[c:t]'' refers to at least one physical drive by channel and target. ''-aN'' here as elsewere is the adapter number [required]<br />
<br />
If the physical drive does not exist or if it isn't in failed state, the utility exits with no harm done.<br />
<br />
An example of this command under our present configuration would be: <br />
megarc -physOn -a0 pd[0:1]<br />
<br />
===megarc -phys -chAll -idAll -a0===<br />
Show the physical drive description for each device on all channels managed by adapter ''0''<br />
<br />
<pre><br />
<br />
Adapter 0, Channel 0, Target ID 1 <br />
Type: DISK Vendor : WDC<br />
Product: WD4000KD-00NAB0 Revision : 01.0<br />
Synchronous : No Wide-32 : No Wide-16: No<br />
LinkCmdSupport: No TagQ support: No RelAddr: No<br />
Removable : No SoftReset : No AENC : No<br />
etc...<br />
</pre><br />
<br />
===megarc -physdrvSerialInfo -chAll -idAll -a0===<br />
Show the serial number for each physical drive on each channel for all serial devices managed by adapter ''0'' (This doesn't look correct or helpful).<br />
<br />
<pre><br />
Adapter 0, Channel 0, Target ID 1 <br />
<br />
PhysDrvSerial#: WD-W<br />
<br />
etc ...<br />
</pre><br />
<br />
===megarc -pdFailInfo -chAll -idAll -a0===<br />
Show the failure history for each device on all channels managed by adapter ''0''. <br />
<br />
===megarc -setRbldRate|-getRbldRate -a0 ===<br />
Get the rebuild rate for adapter ''0''.<br />
<pre><br />
<br />
# megarc -getRbldRate -a0<br />
<br />
...<br />
<br />
**********************************************************************<br />
RebuildRate of Adapter-0 is 30<br />
**********************************************************************<br />
</pre><br />
<br />
===megarc -ctlrInfo -a0===<br />
Display information about adapter ''0''.<br />
<br />
<pre><br />
**********************************************************************<br />
Information of Adapter-0 (#Adapter(s) on system: 1)<br />
**********************************************************************<br />
<br />
Firmware Version : 713N BIOS Version : G119<br />
Logical Drives : 01 DRAM : 64MB<br />
Rebuild Rate : 30%<br />
Flush Interval : 4 secs<br />
Number Of Chnls : 1 Bios Status : Enabled<br />
Alarm State : Enabled Auto Rebuild : Enabled<br />
FW : SPAN-8, 40-LD BIOS Config AutoSelection : USER<br />
BIOS Echos Mesg : ON BIOS Stops On Error : ON<br />
Initiator Id : 16(Clustered Firmware)<br />
Board SN: -17179869<br />
**********************************************************************<br />
</pre><br />
<br />
===megarc -getXFerRate|-setXFerRate -a0 -chAll===<br />
Get or set the transfer rate for all channels on adapter ''0''.<br />
<pre><br />
# megarc -getXFerRate -a0 -ch0<br />
<br />
**********************************************************************<br />
Transfer Rate of Adapter-0 Channel-0 is 160M<br />
**********************************************************************<br />
</pre></div>Jimbohttp://freebsdwiki.net/index.php/Category:RAIDCategory:RAID2012-08-25T22:02:07Z<p>Jimbo: Reverted edits by 173.88.199.104 (talk) to last revision by Ninereasons</p>
<hr />
<div>'''Redundant Array of Inexpensive Disks''', often found on servers, enables multiple hard-drives to be accessed by the system as though they were a single storage device. RAID devices or software can be configured in various [http://en.wikipedia.org/wiki/Redundant_array_of_independent_disks#Standard_RAID_levels RAID levels], to boost disk performance (faster reading and writing) and/or for fault-tolerance (so that if a physical disk fails, the failed disk can be replaced without loss of data; and pending replacement the data will continue to be available). To add an article to this sub-category of [[:Category:FreeBSD for Servers]], add <nowiki>[[Category:RAID]]</nowiki> to the end of the article.<br />
<br />
[[Category:FreeBSD for Servers]]</div>Jimbohttp://freebsdwiki.net/index.php/RAIDRAID2012-08-25T22:01:32Z<p>Jimbo: </p>
<hr />
<div>[[RAID]] is an acronym for Redundant Array of Inexpensive Devices - in other words, a way to use multiple physical drives to support a single logical storage volume. There are many different types of RAID, with the most common variants being as follows:<br />
<br />
[[RAID0]] - striping without parity (added storage space, decreased reliability) - NOT recommended!<br />
[[RAID1]] - simple mirroring (added access speed and reliability, no change to storage space)<br />
[[RAID3]] - striping with a single parity provider (added storage space, added reliability)<br />
[[RAID5]] - striping with distributed parity across all providers (added storage space, added reliability)<br />
<br />
FreeBSD offers solid and reliable kernel-level software RAID at the [[RAID0]], [[RAID1]], and [[RAID3]] levels via the [[geom]] module. (Examples of installation and usage are present at many of the individual RAID level articles above.) <br />
<br />
Geom [[RAID5]] is available via patches, but has not been implemented in the base system yet - and many argue that [[RAID3]], while not as commonly seen in the outside world, is actually a superior setup anyway. ([[User:Jimbo|Jimbo]] agrees with this statement.)<br />
<br />
[[Category:FreeBSD Terminology]]<br />
[[Category:FreeBSD for Servers]]<br />
[[Category:RAID]]</div>Jimbohttp://freebsdwiki.net/index.php/GvinumGvinum2012-08-25T22:00:59Z<p>Jimbo: </p>
<hr />
<div>(NOTE: for practical tasks, you should probably see [[gmirror]] or [[graid3]] instead of this article.)<br />
<br />
'''{{PAGENAME}}''' is a Logical Volume Manager, providing kernel-level software [[RAID]] for the FreeBSD (and NetBSD) operating systems. ''Gvinum'' is the replacement, since FreeBSD 5.3, for the [http://www.vinumvm.org/ ''Vinum'' Volume Manager], re-written to utilize [[geom]] communication methods, and is included in the FreeBSD core distribution. Many of the ''vinum'' functions are reproduced in ''gvinum'', but not all.</div>Jimbohttp://freebsdwiki.net/index.php/ZFS,_booting_from_(pre_9.0-RELEASE)ZFS, booting from (pre 9.0-RELEASE)2012-08-25T21:59:13Z<p>Jimbo: </p>
<hr />
<div>Note: this article was taken very nearly verbatim from Scott Hetzel's excellent guide at [http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/Mirror http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/Mirror].<br />
<br />
=Installing FreeBSD Root on ZFS (Mirror) using GPT=<br />
<br />
==Creating a bootable ZFS Filesystem==<br />
<br />
Boot FreeBSD install DVD or USB Memstick, and choose the Fixit option in sysinstall.<br />
<br />
===Create GPT Disks===<br />
<br />
Fixit# gpart create -s gpt ad0<br />
Fixit# gpart create -s gpt ad1<br />
<br />
===Create the boot, swap and zfs partitions===<br />
<br />
Create 3 partitions on both drives ad0 and ad1. The first partition contains the gptzfsboot loader which is able to recognize and load the loader from a ZFS partition. The second partition is a 4 GB swap partition. The third partition is the partition containing the zpool (20GB).<br />
<br />
Fixit# gpart add -b 34 -s 128 -t freebsd-boot -l boot0 ad0<br />
Fixit# gpart add -b 162 -s 8388608 -t freebsd-swap -l swap0 ad0<br />
Fixit# gpart add -b 8388770 -s 41943040 -t freebsd-zfs -l root0 ad0<br />
<br />
Fixit# gpart add -b 34 -s 128 -t freebsd-boot -l boot1 ad1<br />
Fixit# gpart add -b 162 -s 8388608 -t freebsd-swap -l swap1 ad1<br />
Fixit# gpart add -b 8388770 -s 41943040 -t freebsd-zfs -l root1 ad1<br />
<br />
Notes:<br />
1. While a ZFS Swap Volume can be used instead of the freebsd-swap partition, crash dumps can't be created on the ZFS Swap Volume.<br />
2. Sizes and offsets are specified in sectors (1 sector is typically 512 bytes). <br />
3. You may issue a '''gpart show''' command to see the correct location and size for further partitions you might need.<br />
<br />
===Install the Protected MBR (pmbr) and gptzfsboot loader to both drives===<br />
<br />
Fixit# gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1 ad0<br />
Fixit# gpart bootcode -b /mnt2/boot/pmbr -p /mnt2/boot/gptzfsboot -i 1 ad1<br />
<br />
This may fail with an "operation not permitted" error message, since the kernel likes to protect critical parts of the disk. If this happens for you, run:<br />
<br />
Fixit# sysctl kern.geom.debugflags=0x10<br />
<br />
===Create the root ZFS Pool===<br />
<br />
Fixit# kldload /mnt2/boot/kernel/opensolaris.ko<br />
Fixit# kldload /mnt2/boot/kernel/zfs.ko<br />
Fixit# mkdir /boot/zfs<br />
Fixit# zpool create zroot mirror /dev/gpt/root0 /dev/gpt/root1<br />
Fixit# zpool set bootfs=zroot zroot<br />
<br />
=Install FreeBSD to zroot=<br />
<br />
==Optional: Create ZFS datasets specifically for a FreeBSD system==<br />
<br />
If you wish, you may [[ZFS, creating datasets for the FreeBSD system|set up ZFS datasets within the zroot pool specifically optimized for the FreeBSD system]]. <br />
<br />
I wish to stress that this is ''optional'', and many admins may prefer to simply install to the single 20GB zroot pool already set up - among other things, following the guide linked to will cause ''sixteen'' new filesystems to show up in the output of '''df'''!<br />
<br />
If this sounds like more trouble than it's worth, skip this step completely and move on.<br />
<br />
==Optional: Change the checksum algorithm==<br />
<br />
The fletcher4 algorithm should be more robust than the fletcher2 algorithm.<br />
<br />
Fixit# zfs set checksum=fletcher4 zroot<br />
<br />
==Installing the system==<br />
<br />
Fixit# cd /zroot<br />
Fixit# cd /dist/8.0-*<br />
Fixit# export DESTDIR=/zroot<br />
Fixit# for dir in base catpages dict doc games info lib32 manpages ports; \<br />
do (cd $dir ; ./install.sh) ; done<br />
Fixit# cd src ; ./install.sh all<br />
Fixit# cd ../kernels ; ./install.sh generic<br />
Fixit# cd /zroot/boot ; cp -Rlp GENERIC/* /zroot/boot/kernel/<br />
<br />
==Initial configuration of the new system==<br />
<br />
=== chroot into the new system ===<br />
Fixit# chroot /zroot<br />
<br />
=== create a /home directory ===<br />
<br />
If you didn't create a dataset for home in the [[ZFS, creating datasets for the FreeBSD system|optional steps above]], you'll need to create a directory for it now.<br />
<br />
Fixit# mkdir /usr/home<br />
Fixit# ln -s /usr/home home<br />
<br />
=== configure /etc/rc.conf ===<br />
Fixit# echo 'zfs_enable="YES"' > /etc/rc.conf<br />
Fixit# echo 'hostname="beastie.mydomain.local"' >> /etc/rc.conf<br />
Fixit# echo 'ifconfig_re0="DHCP"' >> /etc/rc.conf<br />
<br />
Note:<br />
Replace re0 with the name of the Network interface for the new system <br />
<br />
=== configure /boot/loader.conf ===<br />
Fixit# echo 'zfs_load="YES"' > /boot/loader.conf<br />
Fixit# echo 'vfs.root.mountfrom="zfs:zroot"' >> /boot/loader.conf<br />
<br />
Check your loader.conf, and make CERTAIN you the quotes in "zfs:zroot" showed up - your system '''will not boot''' if they're not there!<br />
<br />
=== Change root's password ===<br />
<br />
Fixit# passwd<br />
<br />
=== Set the local time zone ===<br />
<br />
Fixit# tzsetup<br />
<br />
=== Create /etc/mail/aliases.db ===<br />
<br />
Fixit# cd /etc/mail<br />
Fixit# make aliases<br />
<br />
<br />
==Installing ZFS aware /boot/loader (Required for 8.0-RELEASE and 7.{0-2}-RELEASE)==<br />
<br />
'''Note''': This step is obsoleted in FreeBSD 8.0-STABLE, FreeBSD 9.0-CURRENT, FreeBSD 7.2-STABLE, and newer.<br />
<br />
Fixit# echo 'LOADER_ZFS_SUPPORT=YES' > /etc/src.conf<br />
Fixit# mount -t devfs devfs /dev<br />
Fixit# export DESTDIR=""<br />
Fixit# cd /usr/src/sys/boot/<br />
Fixit# make obj<br />
Fixit# make depend<br />
Fixit# make<br />
Fixit# cd i386/loader<br />
Fixit# make install<br />
Fixit# umount /dev<br />
<br />
== Exit from the /zroot ==<br />
<br />
Fixit# exit<br />
<br />
== Install zpool.cache to the ZFS filesystem ==<br />
<br />
Fixit# cp /boot/zfs/zpool.cache /zroot/boot/zfs/zpool.cache<br />
<br />
= Finishing the installation =<br />
<br />
==Using swap==<br />
<br />
There are 2 ways to use the gpt/swap0 and gpt/swap1 partitions. '''Only choose one!'''<br />
<br />
===Create /etc/fstab to use both swap partitions===<br />
<br />
Fixit# cat << EOF > /zroot/etc/fstab<br />
# Device Mountpoint FStype Options Dump Pass#<br />
/dev/gpt/swap0 none swap sw 0 0<br />
/dev/gpt/swap1 none swap sw 0 0<br />
EOF<br />
<br />
===Use gmirror to mirror the swap partitions===<br />
<br />
Fixit# kldload /mnt2/boot/kernel/geom_mirror.ko<br />
Fixit# gmirror label -b prefer swap gpt/swap0 gpt/swap1<br />
<br />
Note: The 'prefer' balance algorithm can be replaced by 'round-robin'. See the gmirror(8) man page about problem using the 'round-robin' balance algorithm and kernel dumps<br />
<br />
Fixit# cat << EOF > /zroot/etc/fstab<br />
# Device Mountpoint FStype Options Dump Pass#<br />
/dev/mirror/swap none swap sw 0 0<br />
EOF<br />
<br />
Fixit# echo 'geom_mirror_load="YES"' >> /zroot/boot/loader.conf<br />
<br />
<br />
== Setting mountpoints before first boot ==<br />
<br />
Fixit# export LD_LIBRARY_PATH=/mnt2/lib <br />
Fixit# cd /<br />
Fixit# zfs unmount -a<br />
Fixit# zfs set mountpoint=legacy zroot<br />
<br />
If you set up the full hierarchy of ZFS datasets for the system in the optional steps above, you need to set their mountpoints as well:<br />
<br />
Fixit# zfs set mountpoint=/tmp zroot/tmp<br />
Fixit# zfs set mountpoint=/usr zroot/usr<br />
Fixit# zfs set mountpoint=/var zroot/var<br />
<br />
Exit Fixit mode and sysinstall. Remove the FreeBSD install DVD/Memstick and the system will boot using the ZFS root. <br />
<br />
[[Category:ZFS]] [[Category:FreeBSD for Servers]] [[Category:RAID]]</div>Jimbohttp://freebsdwiki.net/index.php/ZFS,_booting_fromZFS, booting from2012-08-25T21:58:53Z<p>Jimbo: </p>
<hr />
<div>Note: '''THIS ARTICLE IS FOR 9.0-RELEASE AND UP!''' If you're using FreeBSD 7.x or 8.x, please see [[ZFS, booting from (pre 9.0-RELEASE)]].<br />
<br />
=Installing FreeBSD Root on ZFS (Mirror) using GPT=<br />
<br />
==Creating a bootable ZFS Filesystem==<br />
<br />
Boot FreeBSD install DVD or USB Memstick, and choose Install. Choose your keyboard mapping, hostname, and distribution components (doc, games, lib32, ports, and src - I'd highly advise you to leave ports selected!) as normal. At the Partitioning stage, select <'''S'''hell>.<br />
<br />
===Create GPT Disks===<br />
<br />
In this stage we'll assume you have two drives, ada0 and ada1 - check your device names ('''ls /dev/ada*''') and adjust as appropriate, and of course if you have more drives, copy these commands for those drives as well. <br />
<br />
# gpart create -s gpt ada0<br />
# gpart create -s gpt ada1<br />
<br />
===Create the boot, swap and zfs partitions===<br />
<br />
Create 3 partitions on both drives ada0 and ada1. The first partition contains the gptzfsboot loader which is able to recognize and load the loader from a ZFS partition. The second partition is a 4 GB swap partition. The third partition is the partition containing the zpool (20GB). NOTE: you'll greatly decrease your chance of fat-finger mistakes if for each new command, you use the up-arrow key to duplicate the previous line, then just edit the parameters as appropriate!<br />
<br />
# gpart add -b 34 -s 128 -t freebsd-boot -l boot0 ada0<br />
# gpart add -b 34 -s 128 -t freebsd-boot -l boot1 ada1<br />
# gpart add -b 162 -s 8388608 -t freebsd-swap -l swap0 ada0<br />
# gpart add -b 162 -s 8388608 -t freebsd-swap -l swap1 ada1<br />
# gpart add -b 8388770 -s 41943040 -t freebsd-zfs -l root0 ada0<br />
# gpart add -b 8388770 -s 41943040 -t freebsd-zfs -l root1 ada1<br />
<br />
Notes:<br />
1. While a ZFS Swap Volume can be used instead of the freebsd-swap partition, crash dumps can't be created on the ZFS Swap Volume.<br />
2. Sizes and offsets are specified in sectors (1 sector is typically 512 bytes). <br />
3. You may issue a '''gpart show''' command to see the correct location and size for further partitions you might need.<br />
<br />
===Install the Protected MBR (pmbr) and gptzfsboot loader to both drives===<br />
<br />
# gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0<br />
# gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada1<br />
<br />
This may fail with an "operation not permitted" error message, since the kernel likes to protect critical parts of the disk. If this happens for you, run:<br />
<br />
# sysctl kern.geom.debugflags=0x10<br />
<br />
===Create the root ZFS Pool===<br />
<br />
# zpool create -o altroot=/mnt zroot mirror gpt/root0 gpt/root1<br />
# zpool set bootfs=zroot zroot<br />
<br />
=Install FreeBSD to zroot=<br />
<br />
==Optional: Create ZFS datasets specifically for a FreeBSD system==<br />
<br />
If you wish, you may [[ZFS, creating datasets for the FreeBSD system|set up ZFS datasets within the zroot pool specifically optimized for the FreeBSD system]]. <br />
<br />
I wish to stress that this is ''optional'', and many admins may prefer to simply install to the single 20GB zroot pool already set up - among other things, following the guide linked to will cause ''sixteen'' new filesystems to show up in the output of '''df'''!<br />
<br />
If this sounds like more trouble than it's worth, skip this step completely and move on.<br />
<br />
==Optional: Change the checksum algorithm==<br />
<br />
The fletcher4 algorithm should be more robust than the fletcher2 algorithm.<br />
<br />
# zfs set checksum=fletcher4 zroot<br />
<br />
==Installing the system==<br />
<br />
# exit<br />
<br />
Now you'll be back in the normal installer, and it will start decompressing and copying files as usual. This shouldn't take too long. Enter a root password as prompted. Configure your network interface(s) and system time as usual. Choose your system boot services (usually sshd and ntpd). Enable crash dumps (recommended). Add a user account if you want to. Now, back at the "Final Configuration" menu, '''E'''xit. Now at "Manual Configuration", when asked if you would like to open a shell to make any final manual modifications, '''select No.''' This is a lie, but it's a lie you have to tell! '''NOW''', at the "Complete" menu, when asked "Would you like to reboot into the installed system now?" select <'''L'''ive CD>.<br />
<br />
Log in as root - you will not be prompted for a password - and make some necessary final configuration changes. '''Your system will not boot if you forget these steps!'''<br />
<br />
==Initial configuration of the new system==<br />
<br />
=== configure /etc/rc.conf ===<br />
hostname# echo 'zfs_enable="YES"' >> /mnt/etc/rc.conf<br />
<br />
=== configure /boot/loader.conf ===<br />
hostname# echo 'zfs_load="YES"' >> /mnt/boot/loader.conf<br />
hostname# echo 'vfs.root.mountfrom="zfs:zroot"' >> /mnt/boot/loader.conf<br />
<br />
Check your loader.conf, and make CERTAIN you the quotes in "zfs:zroot" showed up - your system '''will not boot''' if they're not there!<br />
<br />
== Install zpool.cache to the ZFS filesystem ==<br />
<br />
hostname# zpool export zroot<br />
hostname# zpool import -o altroot=/mnt -o cachefile=/tmp/zpool.cache zroot<br />
hostname# cp /tmp/zpool.cache /mnt/boot/zfs/<br />
<br />
= Finishing the installation =<br />
<br />
==Using swap==<br />
<br />
===Create /etc/fstab to use both swap partitions===<br />
<br />
hostname# cat << EOF > /mnt/etc/fstab<br />
# Device Mountpoint FStype Options Dump Pass#<br />
/dev/gpt/swap0 none swap sw 0 0<br />
/dev/gpt/swap1 none swap sw 0 0<br />
EOF<br />
<br />
==Reboot into your new system==<br />
<br />
hostname# reboot<br />
<br />
The system will now reboot into your new installation. Enjoy!<br />
<br />
[[Category:ZFS]] [[Category:FreeBSD for Servers]] [[Category:RAID]]</div>Jimbohttp://freebsdwiki.net/index.php/RAID,_performance_testsRAID, performance tests2012-08-25T21:55:23Z<p>Jimbo: Reverted edits by 173.88.199.104 (talk) to last revision by Jimbo</p>
<hr />
<div>= Overview of Array Types =<br />
<br />
== RAID1: Simple Mirroring ==<br />
While RAID1 offers slow write speeds and even some read performance disadvantages when compared to array types such as RAID3, RAID5, or RAID0+1, it does offer one potentially gigantic advantage that the more complex arrays can't: simplicity and survivability. If you lose a RAID controller, lose one or more drives, even forget how RAID works or what it means, any one single surviving member drive of a RAID1 array may be hooked up to a normal drive controller and operated as a standalone drive.<br />
<br />
RAID1 is the performance leader when it comes to massively parallel read processes, but offers little or no read performance benefit to a lightly loaded server or workstation which is usually only serving one request at a time.<br />
<br />
<br />
== RAID0+1: The Mirrored Stripe Set ==<br />
RAID0, unlike RAID1, offers drastically improved write performance and also drastically improved single-read performance. However, RAID0 does not offer parity, meaning that loss of a single member drive means irrevocable loss of all data on the array. RAID0+1 is an attempt to offer the best of both worlds, by creating a stripe set of mirrored pairs - offering most of the advantages of both protocols with few of the flaws of either. You must lose at least two member drives to cause dataloss in a RAID0+1 array, and further the two drives must be both members of a single mirrored pair, making this an extremely survivable array type in regard to member failure. <br />
<br />
While RAID0+1 does offer high performance and high survivability, it also requires a lot of drives for a relatively small array, and still can't offer the "plug any single member in as a singleton and go" safety blanket of pure RAID1. Like the other striping array types, if you lose the RAID controller itself you may have a scary nail-biter of a time trying to recover the array on replacement hardware.<br />
<br />
<br />
== RAID3/RAID4: Stripe Set with Parity Member ==<br />
RAID3 is a RAID0 array with an extra member which gets a parity chunk written to it for each chunk written to the data members. RAID4 is just like RAID3, but uses block-level parity rather than byte-level parity. RAID3/RAID4 offer significant performance benefits across the board, from write performance to single-read performance to multi-read performance, although not as large a multi-read boost as proper RAID1 implementations do. The parity member also allows you to lose any single drive without losing the array, but loss of ''any'' second member is sufficient to kill the array.<br />
<br />
Use of the parity member in read operations is optional with FreeBSD's RAID3 implementation ([[graid3]]), but testing seems to show round-robin parity member reads offering little to no performance benefit with potentially severe performance decreases, so it doesn't seem to be a good idea for most settings.<br />
<br />
'''Graid3''' only allows array sizes of 2^n-1 - ie 3, 5, 9, and so on. This may be a significant handicap to those trying to squeeze the absolute most out of an array without breaking the bank. Linux's RAID4 does not suffer from this limitation.<br />
<br />
RAID3 is extremely rare outside the FreeBSD world - I have neither seen nor heard of it in actual use other than with '''graid3''' under FreeBSD. It is similarly rare to see RAID4 outside Linux's implementation.<br />
<br />
<br />
== RAID5: Stripe Set with Distributed Parity ==<br />
RAID5 is extremely similar to RAID3, except that parity blocks are distributed among all member drives - where a RAID3 array with 5 member drives will write 4 blocks to members 1,2,3,4 and then a parity block to member 5, a RAID5 array with 5 member drives will instead write ''five'' blocks to members 1,2,3,4,5 and then a parity block to member 1 - and on the next cycle, will write five data blocks to 2,3,4,5,1 and then a parity block to member 2.<br />
<br />
RAID5 and RAID3 are obviously extremely similar. Although RAID5 has dominated the industry as a whole for decades, there has been some controversy in recent years over their relative performance levels. We will test both types in this article.<br />
<br />
FreeBSD does not currently support software RAID5 at all. Even inexpensive "hardware" controllers such as the Nvidia onboard types (which use the CPU to XOR data blocks to generate parity and vice versa, and are frequently referred to as "fakeraid") are unsupported. True hardware controllers which do not use the CPU for parity calculation are, of course, supported.<br />
<br />
= Results =<br />
<br />
== RAID1 Mirror Performance ==<br />
<br />
[[image:gmirror-performance.png | Click for raw data and test equipment information]]<br />
<br />
[[Gmirror]], unfortunately, is not doing well at all at this time. 2-drive and 3-drive gmirror arrays performed grossly worse than even a single baseline drive, with a 5-drive gmirror managing to outperform the baseline 250GB drive tested but being handily beaten by the 500GB baseline drive, the Nvidia onboard RAID1 implementation, and especially the Linux RAID1 implementations, which handily dominated everything across the board. <br />
<br />
Only results for [[gmirror]]'s '''round-robin''' balance algorithm are shown here, because the '''load''' and '''split''' balance algorithms performed even more poorly than round-robin. Results for '''split''' are available as raw data if you click the image, but were not included on the graph itself. '''Load''' results are not available because initial testing showed it performing even worse than '''split''' and so the tests were not allowed to complete.<br />
<br />
It is interesting to note that the Nvidia, Promise, and Linux RAID1 implementations all display a significant variation in how they handle simultaneous processes - all three exhibited differences up to 15, 30, and even 38 seconds in times to process otherwise identical simultaneously begun '''cp''' processes to /dev/null. While '''gmirror''''s sheer performance is abysmal, it is worth noting that it does at least handle processes consistently; it never finished processes more than a few hundred milliseconds apart.<br />
<br />
The Promise TX-2300 RAID1 implementation was just plain poor, performing nearly as badly as '''gmirror''' but still failing to improve on the scores of the single baseline drive, while still turning in oddly inconsistent times as the vastly higher-performing arrays did.<br />
<br />
The Gmirror and Linux implementations were the only ones tested which allowed RAID1 arrays with more than two member drives.<br />
<br />
<br />
<br />
== Complex Array Performance ==<br />
<br />
[[image:graid-performance.png | Click for raw data and test equipment information]]<br />
<br />
[[Graid3]] is doing noticeably better than [[gmirror]]. The 5-drive Graid3 implementation handily outperformed the 2-drive mirror across the board, and the 3-drive Graid3 implementation performed somewhat slower than the Linux or Nvidia 2-drive RAID1 arrays in the 2- and 3-process tests and significantly slower in the 4-process and 5-process tests, but nearly doubled their single-process performance. Also, even the 3-member '''graid3''' array (which only has two actual data members) handily outperformed the individually much faster 500GB baseline drive, which both the 2- and 3-member '''gmirror''' arrays inexplicably failed to do. With that said, however, Linux's RAID4 array came very close to its single process performance and beat it like a drum across the rest of the board.<br />
<br />
Nvidia's RAID0+1 presents a compelling challenge, clearly outperforming the 5-drive '''graid3''' array in the 3, 4, and 5 process tests - but equally significantly, it's roughly on par for the 2-process test and ''drastically'' slower on the single-process test, even getting outperformed by the 3-drive RAID3 array. We'll go into more of what that means for the real world in the overall high performance section next.<br />
<br />
Linux's RAID5 and RAID4 implementations both handily outperform 6.2-RELEASE's RAID3 under heavy load, but for single process performance '''graid3''' is the pick of the litter out of all systems tested.<br />
<br />
Only results for [[graid3]]'s default configuration are shown here, because the '''-r''' configuration (always use the parity member during reads) performed slightly to significantly poorer in all but the 5-process test, in which it performed only very slightly better. It is possible that a more massively parallel test (or a test of a much less contiguous filesystem) would show some advantage to '''-r''', but for these tests, no advantage is apparent. Raw data is available on the image page itself.<br />
<br />
<br />
<br />
== High Performance RAID ==<br />
<br />
[[Image:High_Performance_RAID.png]]<br />
<br />
In this section we'll look briefly at the best performers from both the mirrors and the complex arrays tested previously. This graph particularly shows how important it is to understand the target environment when designing a storage array: we have a bewildering collection of performances completely unlike one another here.<br />
<br />
While the 5-member Linux RAID1 array clearly dominates the field for massively multiple reads, its performance in the 1- and 2-process tests leaves a lot to be desired. Most servers, much less workstations, in the small-office arena that would be seriously considering software RAID in the first place are probably not going to put anywhere near that heavy a load on a server, making the complex arrays look much more practical. Worse, although there are no graphs up yet, the write performance on RAID1 arrays is abysmal - at absolute best, they're a little below baseline for a single member drive. This array would be a good choice for a relatively small (the size of the array is only the size of a single member drive, remember) but massively loaded database that needed to serve large numbers of concurrent requests all day long, or possibly for a medium-load server with a truly paranoid admin, but otherwise if you're going to burn five drives on an array you would probably be served better with one of the complex (striped) types.<br />
<br />
For a lightly loaded workstation or server, FreeBSD's '''graid3''' is at least respectable, turning in the highest single-process performance and not doing too shabbily in two-process performance.<br />
<br />
The RAID0+1 configuration is a solid choice for truly paranoid administrators, with decent though not overwhelming performance clear across the board, some write acceleration, and extreme survivability (a minimum of two drive failures are needed to bring down the array). However, Linux RAID5 and RAID4 outperform it all across the board, and FreeBSD RAID3 outperforms it for 1 or 2 concurrent processes. RAID5, RAID4, and RAID3 also offer better write acceleration as well as producing an array twice the size of the 0+1 with roughly the same number of member drives.<br />
<br />
Finally, Linux's RAID5 and RAID4 arrays are truly solid choices across the board: they outperform everything but '''graid3''' on the single-process test, outperform all other contenders on the 2-process test, and outperform everything but the 5-member RAID1 across the rest of the board. When comparing these two to one another, RAID4 seems like the clear winner despite RAID5's much larger popularity: roughly 25% higher performance on the single-process test means a significant performance bump for most server and workstation features, with the other tests remaining about on par with RAID5.<br />
<br />
<br />
= Conclusions =<br />
<br />
Unfortunately, FreeBSD as of 6.2-RELEASE is clearly lagging behind the times in the software RAID department. The good news is, in several years of this tester's usage of '''gmirror''' it has proven perfectly reliable and easy to set up and use. The bad news is, it is an absolute performance dog, lagging behind a single baseline drive in every possible test. <br />
<br />
'''Graid3''' performs much better than '''gmirror''', and manages to take top honors of all arrays tested in single-process read performance, but it suffers from immediate and drastic performance penalties under heavier load. Linux's RAID4, on the other hand, comes extremely close to '''graid3''' in single-process performance, and both Linux RAID4 and Linux RAID5 roughly ''double'' '''graid3''''s performance across the rest of the board.<br />
<br />
In short, if you have other good reasons to want to run FreeBSD on your server, '''graid3''' is a workable if unimpressive solution to add some fault tolerance and a significant amount of performance to your hard drive storage. But if array performance is a higher priority in and of itself than choice of *nix - for example, in a simple Samba server - you will likely be better served running a modern Linux. With any luck, this will change in later versions of FreeBSD, but for the moment the numbers brook no argument.<br />
<br />
<br />
= Equipment =<br />
<br />
* FreeBSD 6.2-RELEASE (amd64) <br />
* Ubuntu Server 7.04 (amd64)<br />
* Athlon X2 5000+ <br />
* 2GB DDR2 SDRAM <br />
* Nvidia nForce MCP51 SATA 300 onboard RAID controller<br />
* Promise TX2300 SATA 300 RAID controller <br />
* 3x Western Digital 250GB drives (WDC WD2500JS-22NCB1 10.02E02 SATA-300) <br />
* 2x Western Digital 500GB drives (WDC WD5000AAKS-00YGA0 12.01C02 SATA-300)<br />
<br />
= Methodology =<br />
The read-ahead cache was changed from the default value of 8 to 128 for all tests performed, using '''sysctl -w vfs.read_max=128'''. Initial testing showed that dramatic performance increases occurred for ''all'' tested configurations, including baseline single-drive, with increases of vfs.read_max. The value of 128 was arrived at by continuing to double vfs.read_max until no further significant performance increase was to be seen (at vfs.read_max=256) and backing down to the last value tried.<br />
<br />
Similarly, for the Linux tests read-ahead cache was changed from the default value of 256 to 4192, using '''hdparm -a4096 /dev/md0'''. Baseline drive performance was not tested under Linux, but extremely erratic initial test results on the first RAID1 configuration tested led me to googling Linux disk performance tweaking so as to make a completely fair comparison. The 4192 value was arrived at by successive doubling and testing until the highest performing value was found, then testing against 3/4 its value. The RAID1 array was created using the command '''mdadm --create /dev/md0 --level raid1 -n 5 --assume-clean /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf''', and subsequently shrunk to three members and then to two members as testing completed. <br />
<br />
When the Linux RAID5 array was created ('''mdadm --create /dev/md0 --level raid5 -n 5 --assume-clean /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf''') I noticed the system changed the default read-ahead cache value to 1024 - quadruple what it had been for the RAID1 array or for individual drives. Upon retesting, I arrived at '''hdparm -a8192 /dev/md0''' as the sweet spot for a 5-member Linux RAID5 array.<br />
<br />
For the actual testing, 5 individual 3200MB files were created on each tested device or array using '''[[dd]] if=[[dev/random|/dev/random]] bs=16m count=200''' as random1.bin - random5.bin. These files were then [[cp]]'ed from the device or array to [[dev/null|/dev/null]]. Elapsed times were generated by echoing a timestamp immediately before beginning the test and immediately at the end of each individual process, and subtracting the beginning timestamp from the last completed timestamp. Speeds shown are simply the amount of data in MB copied to /dev/null (3200, 6400, 9600, 12800, or 16000) divided by the total elapsed time.<br />
<br />
= Notes =<br />
The methodology used produces a very highly contiguous filesystem, which may skew results significantly higher than in some real-world settings - particularly in the single-process test. Presumably the multiple process copy tests would be much less affected by fragmentation in real-world filesystems, since by their nature they require a significant amount of drive seeks between blocks of the individual files being copied throughout the test.<br />
<br />
In the 5-drive Graid3 array tested, the (significantly faster) 500GB drives were positioned as the last two elements of the array. This is significant particularly because this means the parity drive was noticeably faster than 3 of the 4 data drives in this configuration; some other testing on equipment not listed here leads me to believe that this had a favorable impact when using the '''-r''' configuration. There was not, however, enough of an improvement to make the -r results worth including on the graph.<br />
<br />
Write performance was also tested on each of the devices and arrays listed and will be included in graphs at a later date (for now, raw data is available in the discussion page).<br />
<br />
Googling "gmirror performance" and "gmirror slow" did not get me much of a return; just one other individual wondering why his gmirror was so abominably slow - so I reformatted the test system with 6.2-RELEASE (i386) and retested. Unfortunately, the gmirror results did not improve with the change of platform back to i386. It strikes me as very odd that graid3 with only 3 drives (therefore only 2 data drives) outperforms even a ''five''-drive gmirror implementation. And in sharp contrast to '''gmirror''', of course, the Linux kernel RAID1 results speak for themselves.<br />
<br />
[[Category: Common Tasks]] [[Category: FreeBSD for Servers]] [[Category: FreeBSD for Workstations]] [[Category: Configuring FreeBSD]] [[Category: RAID]]</div>Jimbohttp://freebsdwiki.net/index.php/RAID0,_Software,_How_to_setupRAID0, Software, How to setup2012-08-25T21:55:17Z<p>Jimbo: Reverted edits by 173.88.199.104 (talk) to last revision by 74.2.6.146</p>
<hr />
<div>The following is a practical guide to setting up software RAID0 on FreeBSD using the [[GEOM]] subsystem. This may appear to be written as an aide-memoir however it is a real-working example written by the author actually configuring a real system. <br />
<br />
The system is intended to be a file server using Samba.<br />
<br />
== Obligatory warning == <br />
<br />
By using RAID0, you are at least '''doubling''' the chance of data loss over any given period of time. There is '''no''' parity in RAID0, which means that failure of any drive in the array '''will destroy the entire volume.''' If you are well aware of the MTBF (Mean Time Between Failure) ratings of all the drives you will use, understand the increased risk of data loss, and have a satisfactory backup plan to compensate for this, read on. If any of this sounds scary - and it should - [[User:Jimbo|Jimbo]] strongly suggests you consider adding one more drive and setting up a [[RAID3]] array instead.<br />
<br />
== The Hardware ==<br />
<br />
The system comprises of the following hardware:<br />
<br />
* Processor: AMD Athlon XP 3000;<br />
* Motherboard: ASUS KT4AV;<br />
* Memory: 512MB;<br />
* Storage:<br />
** Hard Drive: Maxtor 30GB IDE (for Operating System);<br />
** Hard Drive: Seagate 500GB SATA x2 (for RAID0 file share);<br />
** Hard Drive Controller: Promise PDC20375 SATA150<br />
* Case: basic full-ATX sized;<br />
* PSU: Antec ATX (with SATA power connections).<br />
<br />
The Promise SATA controller is capable of RAID0 and [[RAID1]] however it is being used as a simple hard drive controller for the two SATA Seagate drives since the motherboard has no SATA ports. The RAID0 is provided by the FreeBSD software-based solution documented within this article.<br />
<br />
== The Software ==<br />
<br />
This guide wouldn't be here unless it involved FreeBSD! It is intended that the system will be a file server for media files using [[Samba]] to not only share the files but also to offer [[WINS]] for name resolution on a small LAN.<br />
<br />
== Configuring RAID0 ==<br />
<br />
The following steps are based on a working implementation however it should be broad enough to cover most instances and be used as a guide to others wishing to implement RAID0.<br />
<br />
You will need to [[su]] or otherwise become [[root]] to execute these steps.<br />
<br />
On FreeBSD the RAID0 "driver" is provided by the [[GEOM]] subsystem and is referred to as ''disk striping''. The driver is available as a loadable kernel module called 'geom_striping'. In order to automatically load this driver on boot, the line '''geom_stripe_load="YES"''' needs to be added to the '''/boot/loader.conf''' file. We can avoid having to actually reboot the system now by loading the driver manually, however.<br />
<br />
server# '''kldload geom_stripe'''<br />
<br />
There needs to be a [[mount]] point for this RAID drive. Because this RAID drive is intended to be used with Samba it will be called '/smb' and created as follows.<br />
<br />
server# '''mkdir /smb'''<br />
<br />
In order to establish the RAID0 drive the underlying drives need to be determined. Here we'll use [[grep]] with a [[regexp]] expression to find all kernel messages that begin with 'ad0:' through 'ad9:'. (For SCSI drives we would have used 'da' instead.) This will show us the drives the kernel detected the last time it was booted.<br />
<br />
server# '''dmesg | grep -e "ad[0-9]:"'''<br />
ad0: 29325MB <Maxtor 6E030L0 NAR61590> at ata0-master UDMA133<br />
ad4: 476940MB <Seagate ST3500630AS 3.AAK> at ata2-master SATA150<br />
ad6: 476940MB <Seagate ST3500630AS 3.AAK> at ata3-master SATA150<br />
<br />
This reveals that the drives intended for use as part of the RAID0 setup - the two Seagate drives - have been allocated 'ad4' and 'ad6'. The operating system drive, the Maxtor, is allocated 'ad0'.<br />
<br />
To create the RAID0 drive using the two drives determined above the [[gstripe]] command is used as follows.<br />
<br />
server# '''gstripe label -v st0 /dev/ad4 /dev/ad6'''<br />
Metadata value stored on /dev/ad4.<br />
Metadata value stored on /dev/ad6.<br />
Done.<br />
<br />
This created a RAID0 drive called '''st0''', which is a virtual device the system treats in much the same way as the physical drives found under '''ad4''' and '''ad6'''. The use of '''-v''' instructed the '''gstripe''' command to be more verbose - without that argument, it would have returned us to the prompt completely silently.<br />
<br />
Piping [[dmesg]] through [[grep]] again will reveal more details of what was actually done.<br />
<br />
server# '''dmesg | grep GEOM_STRIPE'''<br />
GEOM_STRIPE: Device st0 created (id=2925520033).<br />
GEOM_STRIPE: Disk ad4 attached to st0.<br />
GEOM_STRIPE: Disk ad6 attached to st0.<br />
GEOM_STRIPE: Device st0 activated.<br />
<br />
The new RAID0 drive is located under '''/dev/stripe/st0'''.<br />
<br />
Before FreeBSD can utilise a drive, whether it is a regular single drive or a [[RAID]] array, it must be initialised and marked as an available drive. This is done by writing a marker to the drive. Under FreeBSD this is done by using the '[[bsdlabel]]' command.<br />
<br />
server# '''bsdlabel -w /dev/stripe/st0'''<br />
<br />
This simply writes to the new virtual device that hosts the RAID0 drive enabling FreeBSD to reference it as an available drive. As a result of this command executing the virtual device shows a single [[slice]] (or "partition" under Microsoft speak) under '''/dev/stripe/st0a'''.<br />
<br />
To allow data to be written to the RAID0 drive it must be formatted. FreeBSD has a native file system called [[UFS2]] but is also capable of reading and writing to file systems of other operating systems. These "foreign" file systems include Microsoft's variations of the FAT system (called 'MSDOS' on FreeBSD). Since Samba will be running locally on this system the file system will be the native UFS2 and is created using the following command.<br />
<br />
server# '''newfs -U /dev/stripe/st0a'''<br />
<br />
The "-U" instructs newfs to enable [[soft updates]] on the file system as it is formatted. The command will fill the screen with output similar to the following.<br />
<br />
/dev/stripe/st0a: 953880.0MB (1953546304 sectors) block size 16384, fragment size 2048<br />
using 5191 cylinder groups of 183.77MB, 11761 blks, 23552 inodes.<br />
with soft updates<br />
super-block backups (for fsck -b #) at:<br />
160, 376512, 752864, 1129216, 1505568, 1881920, 2258272, 2634624, 3010976, 3387328, 3763680, 4140032, 4516384, 4892736, 5269088, 5645440, 6021792, 6398144, <br />
6774496, 7150848, 7527200, 7903552, 8279904, 8656256, 9032608, 9408960, 9785312, 10161664, 10538016, 10914368, 11290720, 11667072, 12043424, 12419776, <br />
12796128, 13172480, 13548832, 13925184, 14301536, 14677888, 15054240, 15430592, 15806944, 16183296, 16559648, 16936000, 17312352, 17688704, 18065056, 18441408, <br />
18817760, 19194112, 19570464, 19946816, 20323168, 20699520, 21075872, 21452224, 21828576, 22204928, 22581280, 22957632, 23333984, 23710336, 24086688, 24463040, <br />
24839392, 25215744, 25592096, 25968448, 26344800, (and on and on...), 1944610944, 1944987296, 1945363648, 1945740000, 1946116352, 1946492704, 1946869056,<br />
1947245408, 1947621760, 1947998112, 1948374464, 1948750816, 1949127168, 1949503520, 1949879872, 1950256224, 1950632576, 1951008928, 1951385280, 1951761632,<br />
1952137984, 1952514336, 1952890688, 1953267040<br />
<br />
The 'newfs' command has many more options available, including one to specify the size of the drive to format meaning it is possible to create more then one 'slice' (again, akin to "partition") on it. Since no such option was specified the entire drive is formatted as one single slice. This resulted in the creation of almost 1TB of storage using the two 500GB drives.<br />
<br />
The final stage in which to permit FreeBSD to access this drive, and from there allow Samba to read and write via network file shares, is to actually mount it. In order to do this the RAID0 drive needs adding as a mountable drive to the '/etc/fstab' file. The following example taken from the above system shows, on the last line, the entry required in particular.<br />
<br />
# Device Mountpoint FStype Options Dump Pass#<br />
/dev/ad0s1b none swap sw 0 0<br />
/dev/ad0s1a / ufs rw 1 1<br />
/dev/ad0s1e /tmp ufs rw 2 2<br />
/dev/ad0s1f /usr ufs rw 2 2<br />
/dev/ad0s1d /var ufs rw 2 2<br />
/dev/acd0 /cdrom cd9660 ro,noauto 0 0<br />
/dev/stripe/st0a /smb ufs rw 2 2<br />
<br />
After a reboot the drive will be mounted as '/smb' however issuing the following command will save a reboot at this stage.<br />
<br />
server# '''mount /dev/stripe/st0a /smb'''<br />
<br />
This will allow you to use the RAID0 drive much like any other drive on the system. The drive can be verified and the free space determined by using the [[df]] command.<br />
<br />
server# '''df -h /smb'''<br />
<br />
The "-h" shows free space in "human readable" blocksize - which may be kilobytes, megabytes, gigabytes, terabytes, or even petabytes as appropriate. (You may also ask for a specific blocksize directly; for example "df -g" shows free space in gigabytes whether that "seems like" the most readable option or not.)<br />
<br />
== Removing RAID0 ==<br />
<br />
While the drives can simply be removed and thereby remove the RAID0 drive the system will very likely become unstable. The following explains the cleaner way to remove a RAID0 drive from a running system.<br />
<br />
Removing the RAID0 configuration will result in loss of all data. '''Ensure all essential data is backed up prior to doing the following.'''<br />
<br />
Ensure any and all services that might use the drive are either stopped or configured to no longer have a dependency to the drive.<br />
<br />
Remove the drives entry from '/etc/fstab' (see above with regards to how it was added) and [[unmount]] the drive from its mount point.<br />
<br />
Using the [[gstripe]] command inform the GEOM driver to unload the RAID0 drive.<br />
<br />
server# '''gstripe unload /dev/stripe/st0a'''<br />
<br />
To ensure the underlying drives of the RAID0 set can be used for other purposes it is recommended the metadata (data used by GEOM, stored on the last sector of each drive, describing the setup in use) is cleared.<br />
<br />
server# '''gstripe clear -v /dev/ad4'''<br />
server# '''gstripe clear -v /dev/ad6'''<br />
<br />
The 'da4' and 'da6' being the drives used in the above example.<br />
<br />
Issuing these commands will result in the following from [[dmesg]], confirming the removal of RAID0 was successful.<br />
<br />
GEOM_STRIPE: Disk '''ad4''' removed from st0.<br />
GEOM_STRIPE: Device st0 removed.<br />
GEOM_STRIPE: Disk '''ad6''' removed from st0.<br />
GEOM_STRIPE: Device st0 destroyed.<br />
<br />
[[Category: Common Tasks]] [[Category: FreeBSD for Servers]]</div>Jimbohttp://freebsdwiki.net/index.php/RAID1,_Software,_How_to_setupRAID1, Software, How to setup2012-08-25T21:55:11Z<p>Jimbo: Reverted edits by 173.88.199.104 (talk) to last revision by 95.222.239.72</p>
<hr />
<div>==Intro==<br />
This is a quick and dirty tutorial on setting up [[gmirror]] software-based RAID1 mirroring on an existing FreeBSD system. The goal is to convert all system partitions - including / and swap - from using the original system drive to running on a mirror consisting of the original drive and a physically identical mirror drive, safely and without losing any data. This will allow faster data read times as well as provide a measure of data and uptime security against individual drive failure.<br />
<br />
==Prerequisites==<br />
You MUST be running FreeBSD 5.3 or newer to use [[gmirror]]. For the purposes of this walkthrough, you will also need two IDENTICAL drives. We will be assuming that those drives are /dev/ad0 and /dev/ad2, with FreeBSD installed and working on /dev/ad0, and /dev/ad2 being either blank and brand-new or having data you no longer care about on it.<br />
<br />
If you are using FreeBSD 5.3, you will also need a copy of Install CD Disc2.<br />
<br />
==Booting into the LiveCD filesystem==<br />
Reboot from the Install CD (FreeBSD 5.4 or above) or from Install CD disc2 (FreeBSD 5.3), and enter Fixit mode. Then get the root filesystem and devfs running:<br />
<br />
# '''chroot /dist'''<br />
Before FreeBSD 7<br />
# '''mount_devfs devfs /dev'''<br />
FreeBSD 7 and newer<br />
# '''mount -t devfs devfs /dev'''<br />
<br />
==Preparing to Create a Mirror==<br />
Make ABSOLUTELY CERTAIN that you don't have any pre-existing GEOM module labels written to either of your drives - because if you do (for instance from having futzed about with this before finding this article, or trying the article once and then trying it again) it will prevent other things from working. So, clean off any preexisting metadata from each drive:<br />
<br />
# '''gmirror clear /dev/ad0'''<br />
# '''gmirror clear /dev/ad2'''<br />
<br />
Before we get started with the actual mirror procedures, we'll make sure the GEOM module is loaded:<br />
<br />
# '''gmirror load'''<br />
<br />
==Creating and Initializing the Mirror==<br />
Now that we've got that sorted out, you've got a decision to make - do you want your new mirror to use round-robin device balancing, or load-based? ('''Split''' balancing is also available, but is beyond the scope of this article. '''man gmirror''' for details.)<br />
<br />
Round-robin balancing simply makes each successive data access request to the next component in the mirror since the last one, whereas load-based tries to intelligently send data access requests to the least loaded component in the mirror. I'm going to assume you want '''load''' balancing, but if you prefer '''round-robin''' or '''split''' read requests simply substitute that in the label command below.<br />
<br />
# '''gmirror label -v -b load gm0 /dev/ad0'''<br />
# '''mount /dev/mirror/gm0s1a /mnt'''<br />
<br />
And we've created and mounted our mirror filesystem, currently with a single physical drive in it - our existing system drive.<br />
<br />
==Reconfiguring the System==<br />
Now it's time to set things up so that we can boot the system to the GEOM mirror itself, not to /dev/ad0 directly. The next two commands will make sure that the GEOM module will load automatically at boot time, and tell the system that the swap file will be on a mirror, not a raw drive. <br />
<br />
# '''echo geom_mirror_load=\"YES\" >> /mnt/boot/loader.conf'''<br />
# '''echo swapoff=\"YES\" >> /mnt/etc/rc.conf'''<br />
<br />
Now we need to fix fstab to refer to the mirror, not to /dev/ad0 itself. You can either manually edit it using [[ee]] or [[vi]] and change all references to /dev/ad0? to /dev/mirror/gm0? - ie /dev/ad0s1b becomes /dev/mirror/gm0s1b - or you can use a [[sed]] command to do it for you:<br />
<br />
# '''sed "s%ad0%mirror/gm0%g" /mnt/etc/fstab > /mnt/etc/fstab.new'''<br />
# '''mv /mnt/etc/fstab /mnt/etc/fstab.old'''<br />
# '''mv /mnt/etc/fstab.new /mnt/etc/fstab'''<br />
<br />
And now we're ready to reboot! So pull the live CD out of the drive, issue a '''shutdown -r now''', and you should come back up nicely with everything just as it was.<br />
<br />
==Adding the New Drive==<br />
The only thing left to do now is to add the physical /dev/ad2 device to your shiny new /dev/mirror/gm0 mirror.<br />
<br />
# '''gmirror insert gm0 /dev/ad2'''<br />
<br />
And that should be all she wrote - the system should automatically start synchronizing the new device into the mirror without any further prompting from you. You can issue a '''gmirror list''' to see both components and make sure everything looks good, and from here on out everything should get handled automagically by the system - monitor [[/var/log/messages]] for any errors or info as needed.<br />
<br />
==External links==<br />
http://people.freebsd.org/~rse/mirror/ a more complicated approach, involving possibly mismatched disks, etc.<br />
http://dannyman.toldme.com/2005/01/24/freebsd-howto-gmirror-system/ the original how-to this article was based upon.<br />
<br />
[[Category:FreeBSD Terminology]]<br />
[[Category:FreeBSD for Servers]]<br />
[[Category:RAID]]</div>Jimbohttp://freebsdwiki.net/index.php/RAID3,_Software,_How_to_setupRAID3, Software, How to setup2012-08-25T21:55:08Z<p>Jimbo: Reverted edits by 173.88.199.104 (talk) to last revision by 68.154.156.88</p>
<hr />
<div>In this example, we will set up a FreeBSD 6.2-RELEASE system with an 80GB SATA system drive at /dev/ad0, and 5 750GB SATA drives available at /dev/ad1 through /dev/ad5. Once we're done, we'll have those 5 750GB SATA drives in a [[RAID3]] array (ie, four data drives plus one parity drive) with a total storage space of 2.8 terabytes. (The volume will only ''show'' 2.6T, but that's because of the 8% FreeBSD reserves by default for [[root]]'s use.) <br />
<br />
# '''graid3 load'''<br />
# '''graid3 label myraid3array ad1 ad2 ad3 ad4 ad5'''<br />
<br />
You just made a RAID3 array... yes, it really was that easy. Check it out:<br />
<br />
# '''graid3 status'''<br />
Name Status Components<br />
raid3/myraid3array COMPLETE ad1<br />
ad2<br />
ad3<br />
ad4<br />
ad5<br />
<br />
Now we need to [[newfs|format]] it (note the '''-U''' argument, to enable Soft Updates on the new array):<br />
<br />
# '''newfs -U /dev/raid3/myraid3array'''<br />
<br />
You'll get ''several'' pages of cluster IDs scrolling by extremely rapidly at this point. On the example 5x750GB array we're discussing here, this step took about 90 seconds and scrolled several thousand lines.<br />
<br />
With the array formatted, now we can mount it:<br />
<br />
# '''mkdir /mnt/myraid3array'''<br />
# '''mount /dev/raid3/myraid3array /mnt/myraid3array'''<br />
<br />
And we're done - we now have a failure-tolerant array available!<br />
<br />
# '''df -h /mnt/myraid3array'''<br />
Filesystem Size Used Avail Capacity Mounted on<br />
/dev/raid3/myraid3array 2.6T 12K 2.6T 0% /mnt/myraid3array<br />
<br />
If you want to mount your new array automatically on boot, just add an entry to [[/etc/fstab]], and add '''geom_raid3_load="YES"''' to [[/boot/loader.conf]] to make sure that the RAID3 module will load at boot time before filesystems are mounted. (The loader.conf entry may not be strictly necessary under all installations, but can't ever hurt.) You're done!<br />
<br />
[[Category:FreeBSD Terminology]]<br />
[[Category:FreeBSD for Servers]]<br />
[[Category:RAID]]</div>Jimbohttp://freebsdwiki.net/index.php/RAID0RAID02012-08-25T21:55:03Z<p>Jimbo: Reverted edits by 173.88.199.104 (talk) to last revision by Jimbo</p>
<hr />
<div>RAID level 0, typically shortened to RAID0 and often referred to as disk striping, is a method by which two or more physical disks masquerade as one single larger disk.<br />
<br />
== Warning ==<br />
<br />
It must be stressed that '''RAID0/JBOD SHOULD NOT BE USED IN PRODUCTION ENVIRONMENTS''' where data integrity and reliability must be assured! This RAID level should only be used where non-essential data needs reading '''and''' writing to disk quickly. Before implementing RAID0, you should first strongly consider using one of the fault tolerant RAID levels such as [[RAID1]], [[RAID3]], or [[RAID5]].<br />
<br />
<br />
<br />
== Advantages ==<br />
<br />
=== Speed ===<br />
Speed is often a factor in choosing this RAID level due to the performance of data reads and writes, as in the following example:<br />
<br />
''Four disks are used to create a single RAID0 disk using a software based RAID driver. A user application saves a 1MiB file to this disk. The RAID0 driver splits the file into four equal-sized chunks (in this case 256KiB each). The driver then writes the first chunk to the first disk, the second chuck to the second disk, and so on until all the chunks are written to its respective disk.''<br />
<br />
When reading data the opposite takes place where each of the four chunks are read from their respective drives and re-assembled into one original file and passed onto the requesting program.<br />
<br />
Theoretically the system can write files (in this example) four times faster using this method then it could to a single disk.<br />
<br />
'''''Note:''' RAID level 0 is not restricted to four disks as in the above example, any number from two to the maximum the system will handle can produce a single RAID0 disk.''<br />
<br />
=== Space ===<br />
Space is another advantage since all disks in the RAID can be utilized to store data. For example three 500GiB drives in a RAID0 set will provide 1.5TB of storage. This differs from other RAID levels that consume one disk for parity in order to provide fault tolerance.<br />
<br />
=== Cost ===<br />
The implementation of this RAID level can be achieved in software thereby reducing the need to purchase dedicated hardware RAID controllers.<br />
<br />
== Disadvantages ==<br />
<br />
=== Unreliability ===<br />
The main disadvantage of this RAID level is the lack of fault tolerance. Since data is split up and written across all the disks within the RAID0 set a failure of one disk will cause the total loss of all data.<br />
<br />
== Variations ==<br />
There are a number of variations that can be applied to this RAID level. The two common ones are:<br />
<br />
=== JBOD ===<br />
<br />
JBOD, which is simply "Just a Bunch Of Disks" is another method of mounting multiple physical drives as a single logical volume. Unlike RAID0, it does not have the requirement of the disks having the same capacity, hence the name. Also unlike RAID0, JBOD does not "stripe" each file across all of the disks in the volume, so it does not provide any speed advantage for accessing any given file. Since there is no performance advantage, and any single disk can be mounted anywhere on the filesystem anyway (ie '''/usr/home''' can be a directory on a drive, or it can be an entire separate drive), there is no good reason to use disk concatenation on a unixlike operating system.<br />
<br />
=== RAID 10 ===<br />
<br />
RAID10, sometimes referred to as RAID level 01, level 0+1, level 1+0, mirrored striping, gives the advantages of RAID0 but with the redundancy and data safe-guarding of RAID1 thereby limited the disadvantages of RAID0.<br />
<br />
This RAID level achieves this by creating two identical RAID0 disks and applying RAID1, or mirroring, over the top of them. This means that if one of the underlying disks in one of the RAID0 sets fails the other RAID0 will retain system and data reliability. However if one disk from both RAID0 sets fails all data will be lost.<br />
<br />
== Uses ==<br />
<br />
Typical usage for this RAID level is in the field of audio and/or video editing or indeed anything that requires rapid data reading and writing without the need to safeguard data loss.<br />
<br />
== Support ==<br />
<br />
FreeBSD supports software based RAID0 through the GEOM disk management subsystem. Hardware based RAID0 is also available through various supported hardware controllers.<br />
<br />
The [http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/geom-striping.html FreeBSD Handbook] has details covering the GEOM RAID0 / Striping subsystem.<br />
<br />
== Guide ==<br />
<br />
There is a working example of implementing RAID0 on FreeBSD documented in the article [[RAID0 (Setup)]].<br />
<br />
[[Category:FreeBSD Terminology]]<br />
[[Category:RAID]]</div>Jimbohttp://freebsdwiki.net/index.php/DmesgDmesg2012-08-25T21:52:44Z<p>Jimbo: Reverted edits by 173.88.199.104 (talk) to last revision by Mixx941</p>
<hr />
<div>'''dmesg''' displays the system message buffer. It's output is just like /var/run/dmesg.boot, although '''dmesg''' displays things that occur after boot as well. It can be helpful in tracking down problems that might not otherwise be noticed. <br />
<br />
For example:<br />
<br />
'''> dmesg'''<br />
[snip]<br />
ad0: 194481MB <Maxtor 6B200R0/BAH41BM0> [395136/16/63] at ata0-master UDMA133<br />
ad1: 194481MB <Maxtor 6B200P0/BAH41BM0> [395136/16/63] at ata0-slave UDMA133<br />
acd0: DVDR <SONY DVD RW DRU-500A/2.1a> at ata1-slave PIO4<br />
ad1: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=3205439<br />
<br />
Or:<br />
<br />
'''> dmesg'''<br />
[snip]<br />
Mounting root from ufs:/dev/ad0s1a<br />
pid 6152 (audacity), uid 1001: exited on signal 11 (core dumped)<br />
<br />
[[Category : System Commands]]</div>Jimbohttp://freebsdwiki.net/index.php/Resolv.confResolv.conf2012-08-25T21:51:02Z<p>Jimbo: Reverted edits by 173.88.199.104 (talk) to last revision by Jimbo</p>
<hr />
<div>Located at /etc/resolv.conf, this file defines your search domains and your DNS servers. You probably don't want more than 4 to 6 search domains and you '''cannot''' have more than three DNS servers listed. The format is:<br />
<br />
domain freebsdwiki.net<br />
nameserver 169.254.1.1<br />
nameserver 172.16.1.1 <br />
<br />
To attempt to resolve incompletely qualified hostnames using more than one domain name if necessary, use:<br />
<br />
search freebsdwiki.net somethingelse.com anotherdomain.org<br />
<br />
In plain english, that line means that if you try to '''ping webserver''' from the shell, your machine will try to resolve '''webserver.freebsdwiki.net''', '''webserver.somethingelse.com''', and '''webserver.anotherdomain.org''' before giving up.<br />
<br />
Be careful with this, you really don't want to have every attempt at a DNS resolution take 15 seconds or more to time out because you have to contact tons of different nameservers due to your "search" string. There is also a pretty obvious potential for namespace overlap and confusion, ie if you have distinct hosts named '''webserver''', '''fileserver''', or '''printserver''' (or whatever) in more than one of your search domains.<br />
<br />
[[Category:Important_Config_Files]][[Category:Configuring FreeBSD]]</div>Jimbohttp://freebsdwiki.net/index.php/BIND,_securingBIND, securing2012-08-25T21:37:35Z<p>Jimbo: </p>
<hr />
<div>==Your DNS network design==<br />
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.<br />
<br />
==Do Not Pass Go, Do Not Collect 200$, Go Directly to Jail==<br />
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).<br />
<br />
==Don't run as root==<br />
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).<br />
<br />
==Use Views==<br />
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.<br />
<br />
==Don't rely on just network security or just host security: use both==<br />
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.<br />
<br />
==Poison is bad==<br />
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:<br />
<br />
# this is an example of a zone file a black hat would use to poison a victim's DNS cache.<br />
# this file is being run by the black hat on his own machine, '''at IP address 1.2.3.4'''.<br />
#<br />
poisoner.tld. IN SOA ns.poisoner.tld hostmaster.poisoner.tld. (34; 10800; 3600; 604800; 10;)<br />
<br />
poisoner.tld. IN NS ns.victim.tld. # this record tells anyone asking about poisoner.tld to go to ns.victim.tld<br />
ns.victim.tld. IN A 1.2.3.4 # this record is the sneaky one - it "helpfully" tells them that the IP<br />
# address for ns1.victim.tld is THIS machine's IP address!<br />
<br />
# this is the bogus version of the victim.tld zone file which the black hat runs on the same<br />
# server as the poison file, above. After ns.victim.tld's cache is poisoned, it will actually<br />
# send users here instead of answering their queries itself!<br />
#<br />
victim.tld. IN SOA ns.victim.tld hostmaster.victim.tld. (34; 10800; 3600; 604800; 10;)<br />
<br />
victim.tld. IN NS ns.victim.tld. # these two records simply say "yes, I'll tell you all about victim.tld, don't <br />
ns.victim.tld. IN A 1.2.3.4 # go anywhere else to ask"<br />
<br />
www.victim.tld. IN A 1.2.3.5 # this is the IP address of a webpage chock full of spammy ads and malware<br />
<br />
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!<br />
<br />
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.<br />
<br />
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.<br />
<br />
To learn more about poisoning, see Daniel J. Bernstein's article at http://cr.yp.to/djbdns/notes.html#poison<br />
<br />
To see if you can be poisoned, see http://ketil.froyn.name/poison.html<br />
<br />
== See Also ==<br />
<br />
[[BIND (installing)]], [[BIND (configuring)]], [[BIND (managing)]]<br />
<br />
==External Links==<br />
<br />
[[http://www.oreilly.com/catalog/dns4/chapter/ch11.html O'Reilly's BIND book's security chapter]]<br />
<br />
[[http://www.boran.com/security/sp/bind_hardening8.html Hardening BIND 8]]<br />
<br />
[[http://www.boran.com/security/sp/bind9_20010430.html Hardening BIND 9]]<br />
<br />
[[http://www.boran.com/security/sp/chrooting_bind.html Info on chroot'ing]]<br />
<br />
[[http://sysadmin.oreilly.com/news/views_0501.html Implementing Views in BIND 9, by Cricket Liu]]. Thumbing through O'Reilly's DNS & BIND book is highly recommended -- Cricket Liu quite literally wrote the book on DNS.<br />
<br />
[[Category:Ports and Packages]]<br />
[[Category:Configuring FreeBSD]]<br />
[[Category:Securing FreeBSD]]<br />
[[Category:DNS]]</div>Jimbohttp://freebsdwiki.net/index.php/BIND,_dynamic_DNS,_failover_A_recordsBIND, dynamic DNS, failover A records2012-08-25T21:37:23Z<p>Jimbo: </p>
<hr />
<div>== The problem: inexpensive but unreliable ISPs ==<br />
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.<br />
<br />
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'''.<br />
<br />
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.<br />
<br />
== The solution: ddns-failover.pl (another freebsdwiki.net original) == <br />
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.<br />
<br />
(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.)<br />
<br />
<nowiki>#!/usr/bin/perl<br />
<br />
# ddns-failover.pl<br />
#<br />
# Copyright (c) 05-20-2006, JRS System Solutions<br />
# All rights reserved under standard BSD license<br />
# details: http://www.opensource.org/licenses/bsd-license.php<br />
#<br />
# Check each of two public IPs for the same multi-homed host,<br />
# and set a dynamic DNS A record to point to the lower latency<br />
# of the two. If both routes are down, delete the hostname<br />
# entirely until one or both IPs come back up.<br />
<br />
$WANDNS1 = 'cable-ip.office.bsdcompany.com';<br />
$WANDNS2 = 'dsl-ip.office.bsdcompany.com';<br />
$HOSTNAME = 'office.bsdcompany.com';<br />
$NAMESERVER = 'coloserver.bsdcompany.com';<br />
$KEYFILE = 'Koffice.bsdcompany.com.+157+15661.private';<br />
$KEYDIR = '/usr/home/ddns';<br />
$TTL = '10';<br />
<br />
@wan1 = split(/\n/,`/sbin/ping -qc 1 -t 1 $WANDNS1`);<br />
@wan2 = split(/\n/,`/sbin/ping -qc 1 -t 1 $WANDNS2`);<br />
<br />
$wan1[0] =~ /\((\d*?\.\d*?\.\d*?\.\d*?)\)/;<br />
$wan1_ip = $1;<br />
if ($wan1_ip == '') { $wan1_ip = 'NO HOST FOUND'; }<br />
$wan2[0] =~ /\((\d*?\.\d*?\.\d*?\.\d*?)\)/;<br />
$wan2_ip = $1;<br />
if ($wan2_ip == '') { $wan2_ip = 'NO HOST FOUND'; }<br />
<br />
$wan1[3] =~ /(\d*?) packets received/;<br />
$wan1_rcvd = $1;<br />
$wan2[3] =~ /(\d*?) packets received/;<br />
$wan2_rcvd = $1;<br />
<br />
$wan1[4] =~ /\/(\d*?\.\d*?)\//;<br />
$wan1_time = $1;<br />
$wan2[4] =~ /\/(\d*?\.\d*?)\//;<br />
$wan2_time = $1;<br />
<br />
if ($wan1_rcvd != 1 && $wan2_rcvd == 1) {<br />
print "WAN1 [$wan1_ip]: NO RESPONSE\nWAN2 [$wan2_ip]: $wan2_time" . "ms\nSET $HOSTNAME: WAN2\n";<br />
$dnsip=$wan2_ip;<br />
} elsif ($wan1_rcvd == 1 && $wan2_rcvd != 1) {<br />
print "WAN1 [$wan1_ip]: $wan1_time" . "ms\nWAN2 [$wan2_ip]: NO RESPONSE\nSET $HOSTNAME: WAN1\n";<br />
$dnsip=$wan1_ip;<br />
} elsif ($wan1_rcvd != 1 && $wan2_rcvd !=1) {<br />
print "WAN1 [$wan1_ip]: NO RESPONSE\nWAN2 [$wan2_ip]: NO RESPONSE\nDELETE $HOSTNAME\n";<br />
$dnsip='NO';<br />
} elsif ($wan1_time <= $wan2_time) {<br />
print "WAN1 [$wan1_ip]: $wan1_time" . "ms\nWAN2 [$wan2_ip]: $wan2_time" . "ms\nSET $HOSTNAME: WAN1\n";<br />
$dnsip=$wan1_ip;<br />
} else {<br />
print "WAN1 [$wan1_ip]: $wan1_time" . "ms\nWAN2 [$wan2_ip]: $wan2_time" . "ms\nSET $HOSTNAME: WAN2\n";<br />
$dnsip=$wan2_ip;<br />
}<br />
<br />
chdir ($KEYDIR);<br />
open (NSUPDATE, "| /usr/sbin/nsupdate -k $KEYFILE");<br />
print NSUPDATE "server $NAMESERVER\n";<br />
print NSUPDATE "update delete $HOSTNAME A\n";<br />
if ($dnsip ne 'NO') {<br />
print NSUPDATE "update add $HOSTNAME $TTL A $dnsip\n";<br />
}<br />
# print NSUPDATE "show\n";<br />
print NSUPDATE "send\n";<br />
close (NSUPDATE);</nowiki><br />
<br />
== Setting up permissions ==<br />
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.<br />
<br />
coloserver# '''pw useradd ddns -s /sbin/nologin -d /usr/home/ddns'''<br />
coloserver# '''mkdir /home/ddns'''<br />
coloserver# '''cp /etc/namedb/zones/keys/Koffice.bsdcompany.com.+157+15661.private .'''<br />
coloserver# '''cp /etc/namedb/zones/keys/Koffice.bsdcompany.com.+157+15661.key .'''<br />
coloserver# '''chmod 400 Koffice.bsdcompany.com.+157+15661.*'''<br />
coloserver# '''chmod 500 ddns-failover.pl'''<br />
coloserver# '''ls -l'''<br />
-r-------- 1 ddns wheel 130 May 20 12:22 Kph34r.tehinterweb.net.+157+23266.key<br />
-r-------- 1 ddns wheel 145 May 20 13:17 Kph34r.tehinterweb.net.+157+23266.private<br />
-r-x------ 1 ddns wheel 3108 May 23 01:27 ddns-failover.pl<br />
coloserver# '''su ddns''<br />
This account is currently not available.<br />
<br />
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.<br />
<br />
== Testing the script manually ==<br />
coloserver# '''sudo -u ddns /usr/bin/perl /usr/home/ddns/ddns-failover.pl'''<br />
WAN1 [128.32.64.5]: 94.302ms<br />
WAN2 [144.69.42.18]: 85.341ms<br />
SET office.bsdcompany.com: WAN2<br />
coloserver# '''ping -qc 1 office.bsdcompany.com'''<br />
PING office.bsdcompany.com (144.69.42.18): 56 data bytes<br />
<br />
--- office.bsdcompany.com ping statistics ---<br />
1 packets transmitted, 1 packets received, 0% packet loss<br />
round-trip min/avg/max/stddev = 85.038/85.038/85.038/0.000 ms<br />
<br />
Perfect! Now, the BSDcompany folks force an apparent fail condition on WAN2 to make sure it fails over properly:<br />
<br />
coloserver# '''nsupdate -k Koffice.bsdcompany.com.+157+15661.private'''<br />
> '''update delete dsl-ip.office.bsdcompany.com'''<br />
> '''send'''<br />
> '''quit'''<br />
coloserver# '''sudo -u ddns /usr/bin/perl /usr/home/ddns/ddns-failover.pl'''<br />
WAN1 [128.32.64.5]: 98.213ms<br />
WAN2 [NO HOST FOUND]: NO RESPONSE<br />
SET office.bsdcompany.net: WAN1<br />
coloserver# '''ping -qc 1 office.bsdcompany.com'''<br />
PING office.bsdcompany.com (128.32.64.5): 56 data bytes<br />
<br />
--- office.bsdcompany.com ping statistics ---<br />
1 packets transmitted, 1 packets received, 0% packet loss<br />
round-trip min/avg/max/stddev = 97.188/97.188/97.188/0.000 ms<br />
<br />
Good! Now they force WAN1 to apparently fail at the same time, to ensure the record is deleted entirely if both WANs go down (so you get an immediate failure response if both WANs are down, instead of having to wait for a pointless and possibly very lengthy network timeout first):<br />
<br />
coloserver# '''nsupdate -k Koffice.bsdcompany.com.+157+15661.private'''<br />
> '''update delete cable-ip.office.bsdcompany.com'''<br />
> '''update delete dsl-ip.office.bsdcompany.com'''<br />
> '''send'''<br />
> '''quit'''<br />
coloserver# '''sudo -u ddns /usr/bin/perl /usr/home/ddns/ddns-failover.pl'''<br />
WAN1 [NO HOST FOUND]: NO RESPONSE<br />
WAN2 [NO HOST FOUND]: NO RESPONSE<br />
DELETE office.bsdcompany.net<br />
coloserver# '''ping -qc 1 office.bsdcompany.com'''<br />
ping: cannot resolve office.bsdcompany.com: Unknown host<br />
<br />
Outstanding.<br />
<br />
== Installing and running the [[crontab]] ==<br />
Now that we've thoroughly tested our script, we can set it up as a [[crontab]] to run once per minute, just like the [[crontab]] that runs [[set-ddns.pl]] on the server ''inside'' the office to update '''cable-ip''' and '''dsl-ip'''.<br />
<br />
coloserver# '''crontab -u ddns -e'''<br />
<br />
* * * * * /usr/bin/perl /usr/home/ddns/ddns-failover.pl > /dev/null<br />
<br />
To be completely thorough, now we'll break the record one last time and let the cron job fix it behind us:<br />
<br />
coloserver# '''nsupdate -k Koffice.bsdcompany.com.+157+15661.private'''<br />
> '''update delete office.bsdcompany.com A'''<br />
> '''send'''<br />
> '''quit'''<br />
coloserver# '''date'''<br />
Tue May 23 04:17:48 EDT 2006<br />
coloserver# '''ping -qc 1 office.bsdcompany.com'''<br />
ping: cannot resolve office.bsdcompany.com: Unknown host<br />
coloserver# '''date'''<br />
Tue May 23 04:18:03 EDT 2006<br />
coloserver# '''ping -qc 1 office.bsdcompany.com'''<br />
PING office.bsdcompany.com (144.69.42.18): 56 data bytes<br />
<br />
--- office.bsdcompany.com ping statistics ---<br />
1 packets transmitted, 1 packets received, 0% packet loss<br />
round-trip min/avg/max/stddev = 86.338/86.338/86.338/0.000 ms<br />
<br />
As soon as the minute ticked over, our crontab fired up and did what it's supposed to. So now that we've thoroughly tested both the script and the tab that runs it, we can forget about it and just use our failover A record without having to think about it anymore.<br />
<br />
[[Category:Common Tasks]]<br />
[[Category:DNS]]</div>Jimbohttp://freebsdwiki.net/index.php/AdministratorAdministrator2012-08-25T21:35:01Z<p>Jimbo: </p>
<hr />
<div>The Administrator is a user account typically found on Microsoft 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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
On Microsoft 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. <br />
<br />
== Important Warning ==<br />
<br />
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!)<br />
<br />
Remember: ''"With great power comes great responsibility."''<br />
<br />
== Notes ==<br />
<br />
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.<br />
<br />
[[Category:Windows Equivalents]]</div>Jimbohttp://freebsdwiki.net/index.php/ACPI,_enablingACPI, enabling2012-08-25T21:33:30Z<p>Jimbo: </p>
<hr />
<div>== Making ACPI work in FreeBSD 5.x ==<br />
<br />
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, Microsoft 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:<br />
<br />
# Do NOT make an SMP kernel<br />
# options SMP # Symmetric MultiProcessor Kernel<br />
nodevice apic<br />
nodevice smp<br />
<br />
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.<br />
<br />
See [[Custom Kernels]] if you need more information on how to find, edit, build, and install a custom kernel in general.<br />
[[Category:Common Tasks]]</div>Jimbohttp://freebsdwiki.net/index.php/AccessPoint_using_pppoeAccessPoint using pppoe2012-08-25T21:31:33Z<p>Jimbo: Reverted edits by DavidYoung (talk) to last revision by Jimbo</p>
<hr />
<div>#REDIRECT [[PPPOE, access point]]</div>Jimbohttp://freebsdwiki.net/index.php/Adding_usersAdding users2012-08-25T21:31:31Z<p>Jimbo: Reverted edits by DavidYoung (talk) to last revision by Jimbo</p>
<hr />
<div>#REDIRECT [[Users, adding]]</div>Jimbohttp://freebsdwiki.net/index.php/Access_Control_ListAccess Control List2012-08-25T21:31:29Z<p>Jimbo: Reverted edits by DavidYoung (talk) to last revision by Jimbo</p>
<hr />
<div>#REDIRECT [[ACL]]</div>Jimbohttp://freebsdwiki.net/index.php/AdduserAdduser2012-08-25T21:31:28Z<p>Jimbo: Reverted edits by DavidYoung (talk) to last revision by Jimbo</p>
<hr />
<div>#REDIRECT [[Users, adding]]</div>Jimbohttp://freebsdwiki.net/index.php/BIND,_configuringBIND, configuring2012-08-25T21:31:26Z<p>Jimbo: Reverted edits by DavidYoung (talk) to last revision by Jimbo</p>
<hr />
<div>#REDIRECT [[named.conf]]<br />
<br />
[[Category:Ports and Packages]]<br />
[[Category:Common Tasks]]<br />
[[Category:DNS]]</div>Jimbohttp://freebsdwiki.net/index.php/BIND_(configuring)BIND (configuring)2012-08-25T21:31:22Z<p>Jimbo: Reverted edits by DavidYoung (talk) to last revision by Jimbo</p>
<hr />
<div>#REDIRECT [[named.conf]]</div>Jimbohttp://freebsdwiki.net/index.php/BIND_(dynamic_DNS)BIND (dynamic DNS)2012-08-25T21:31:21Z<p>Jimbo: Reverted edits by DavidYoung (talk) to last revision by Jimbo</p>
<hr />
<div>#REDIRECT [[BIND, dynamic DNS]]</div>Jimbohttp://freebsdwiki.net/index.php/BIND_(dynamic_DNS,_failover_A_records)BIND (dynamic DNS, failover A records)2012-08-25T21:31:20Z<p>Jimbo: Reverted edits by DavidYoung (talk) to last revision by Jimbo</p>
<hr />
<div>#REDIRECT [[BIND, dynamic DNS, failover A records]]</div>Jimbohttp://freebsdwiki.net/index.php/BIND_(installing)BIND (installing)2012-08-25T21:31:19Z<p>Jimbo: Reverted edits by DavidYoung (talk) to last revision by Jimbo</p>
<hr />
<div>#REDIRECT [[BIND, installing]]</div>Jimbohttp://freebsdwiki.net/index.php/.bashrc.bashrc2012-08-25T21:30:48Z<p>Jimbo: Reverted edits by DavidYoung (talk) to last revision by 200.38.30.168</p>
<hr />
<div>.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. <br />
<br />
dave@samizdata:~% more .bashrc<br />
# ~/.bashrc: executed by bash(1) for non-login shells.<br />
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)<br />
# for examples<br />
<br />
# If running interactively, then:<br />
if [ "$PS1" ]; then<br />
<br />
# don't put duplicate lines in the history. See bash(1) for more options<br />
# export HISTCONTROL=ignoredups<br />
# check the window size after each command and, if necessary,<br />
# update the values of LINES and COLUMNS.<br />
#shopt -s checkwinsize<br />
<br />
# enable color support of ls and also add handy aliases<br />
# if [ "$TERM" != "dumb" ]; then<br />
# eval `dircolors -b`<br />
# alias ls='ls --color=auto'<br />
# alias dir='ls --color=auto --format=vertical'<br />
# alias vdir='ls --color=auto --format=long'<br />
# fi<br />
# some more ls aliases<br />
# alias ll='ls -l'<br />
# alias la='ls -A'<br />
# alias l='ls -CF'<br />
<br />
# less pipes automagically<br />
# eval `lesspipe`<br />
<br />
# set a fancy prompt<br />
PS1='\u@\h:\w% '<br />
<br />
# If this is an xterm set the title to user@host:dir<br />
case $TERM in<br />
xterm*)<br />
PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME}: ${PWD}\007"'<br />
;;<br />
*)<br />
;;<br />
esac<br />
<br />
# enable programmable completion features (you don't need to enable<br />
# this, if it's already enabled in /etc/bash.bashrc).<br />
#if [ -f /etc/bash_completion ]; then<br />
# . /etc/bash_completion<br />
#fi<br />
fi<br />
<br />
[[Category:Important Config Files]]</div>Jimbohttp://freebsdwiki.net/index.php/.htaccess.htaccess2012-08-25T21:30:46Z<p>Jimbo: Reverted edits by DavidYoung (talk) to last revision by 200.38.30.168</p>
<hr />
<div>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!<br />
<br />
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:<br />
<br />
RewriteEngine On<br />
RewriteCond %{HTTPS} off<br />
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}<br />
<br />
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:<br />
<br />
AuthName "Anti-Spam Protection"<br />
AuthType Basic<br />
<Limit PUT POST><br />
order allow,deny<br />
allow from all<br />
<br />
# CHINANET telcom - 2006-03-02<br />
deny from 212.0.0.0/8<br />
deny from 216.0.0.0/8<br />
deny from 218.0.0.0/8<br />
deny from 221.0.0.0/8<br />
deny from 61.144.0.0/14<br />
</Limit><br />
<br />
Note that comments - prefaced by # signs - ARE allowed in .htaccess files. Use this to your advantage!<br />
<br />
What if you want to require a password for a certain directory?<br />
<br />
# require a username and password to get into this lightly secured area<br />
AuthType Basic<br />
# note: it's safest to keep the password file OUTSIDE the webroot!<br />
AuthUserFile ../.htpasswd<br />
AuthName "JRS Systems Personnel Only"<br />
require valid-user<br />
satisfy any<br />
<br />
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.<br />
<br />
[[Category:Important Config Files]]</div>Jimbohttp://freebsdwiki.net/index.php//etc/resolv.conf/etc/resolv.conf2012-08-25T21:30:43Z<p>Jimbo: Reverted edits by DavidYoung (talk) to last revision by 200.38.30.168</p>
<hr />
<div>see resolv.conf</div>Jimbohttp://freebsdwiki.net/index.php//usr/local/etc/rc.d/usr/local/etc/rc.d2012-08-25T21:30:41Z<p>Jimbo: Reverted edits by DavidYoung (talk) to last revision by 200.38.30.168</p>
<hr />
<div></div>Jimbo