% zpool create tank /dev/da2 /dev/da3 /dev/da4 /dev/da5

But, what happens when you reboot without /dev/da2 plugged in? /dev/da3 becomes /dev/da2 and your pool is confused and weird and all that junk.

A simple tip is to create a GPT on each disk you plan to add to a pool and rather than using the device node of /dev/da#p#, use the GPT partition ID device node that’s automatically created under /dev/gptid.

First, wipe the partition table on each of your disks, using:


% dd if=/dev/zero of=/dev/da2 bs=512 count=1
% dd if=/dev/zero of=/dev/da3 bs=512 count=1
% dd if=/dev/zero of=/dev/da4 bs=512 count=1
% dd if=/dev/zero of=/dev/da5 bs=512 count=1


Now create a new GPT on each disk, using:


% gpart create -s gpt da2
% gpart create -s gpt da3
% gpart create -s gpt da4
% gpart create -s gpt da5


Now create a FreeBSD ZFS partition on each disk. This is easy because we’re only making one partition per disk.


% gpart add -t freebsd-zfs da2
% gpart add -t freebsd-zfs da3
% gpart add -t freebsd-zfs da4
% gpart add -t freebsd-zfs da5


You should now see the gptids listed in /dev/gptid/


# ls -l /dev/gptid
total 0
crw-r----- 1 root operator 0, 126 Jan 23 15:44 1bcdc07f-4603-11e1-bd02-003048bb1b96
crw-r----- 1 root operator 0, 135 Jan 23 15:44 1cf8bda4-4603-11e1-bd02-003048bb1b96
crw-r----- 1 root operator 0, 143 Jan 23 15:44 1da00324-4603-11e1-bd02-003048bb1b96
crw-r----- 1 root operator 0, 151 Jan 23 15:45 1e83229b-4603-11e1-bd02-003048bb1b96


Now simply create your zpool however you like, using the gptid device node instead of the device ID.


# zpool create external \
/dev/gptid/1bcdc07f-4603-11e1-bd02-003048bb1b96 \
/dev/gptid/1cf8bda4-4603-11e1-bd02-003048bb1b96 \
/dev/gptid/1da00324-4603-11e1-bd02-003048bb1b96 \
/dev/gptid/1e83229b-4603-11e1-bd02-003048bb1b96


And check on it…


# zpool status external
pool: external
state: ONLINE
scan: none requested
config:

errors: No known data errors


You can use the gpart utility to see all kinds of data about your partitions as well. This is useful to figure out which gptid belongs to which disk.

The only solution seems to be moving all the data away and back. I bought 4 external hard drives, made a storagebomb and away I went. This page has a good description of how to move an entire pool to a different device, preserving all the snapshots and whatnot.

I’ll post my script here later.

1. Read The Config Files!!!

RC’s configuration files are well documented and revisiting that potent, inline documentation can often answer your questions.

• main.inc.php.dist
• db.inc.php.dist

2. Enable Logging

If you’re experiencing undesired behavior, 9 times out of 10, the problem is the way you’ve configured RC. There is no way to identify yourself as the problem, without knowing exactly what it is that RC is doing behind the scenes. For that, you need to enable logging.

Just think… If the problem is in the logs, you won’t have to look stupid when you realize you made a typo on the mail server hostname. Less public ridicule is always a good thing!

Make sure your log directory is able to be written to by the web server!

3. READ THE LOGS

The logging is written in plain English. If you don’t know English, you’re probably not reading this page.

4. Google The Error

Now that you have thoroughly read through the log file and see errors indicating what may be wrong with your configuration, you have everything you need to make important inferences. If these inferences aren’t enough to guide you into a working configuration, it’s time for you to Google the error message. Chances are you’ll find somebody who has had the same issue and has since fixed it. If you’re lucky enough, this kind fellow may have posted the solution to your very problem!

5. Still Need Help?

If you’re unfortunate enough to come to this section having completed the previous sections thoroughly, you’ve either missed something (which happens), or you’ve got a problem that people in the channel will be interested to help you solve! All that’s left is for you to present the problem in a well-thought-out form. You should also make sure to mention the steps you’ve performed to try to fix your issue.

Now that you’ve asked your question, you have only one thing left to do — WAIT. Nobody in the channel is paid to support you, so if they’re busy, they may be disregarding the channel. You get what you pay for.

Extract the ISO

Get your install ISO from somewhere and extract it to some directory.

mkdir ./iso
tar -C ./iso -pxf 8.0-RELEASE-i386-disc1.iso
cd ./iso

loader.conf

Next thing to do is to tell the boot loader to start using the serial port. This can be done by putting:

console="comconsole"

somewhere inside boot/loader.conf (obviously inside the iso directory)

Make the ISO!

Now wrap it all up into an iso using:

mkisofs -J -r -b boot/cdboot -no-emul-boot -o 8.0-RELEASE-i386-disc1-serial.iso ./iso

or something of the sort.

You’re done!

Go burn the ISO file and boot a system off the CD. Set your terminal’s baud rate to 9600 and you’ll eventually see things booting up!

Here’s my process:

Verify Anonymous CVS Connectivity

First, you must verify that you can connect to the anoncvs server. You can find instructions in the FreeBSD Handbook for this process.

One thing you should probably be aware of is that there are a very limited number of anoncvs mirrors, which is why I chose the .tw one.

Prepare Your Ports Tree

You need to be sure that you have an updated portsdb installed so portdowngrade is able to find the matching ports with a search.

portsdb -u

Installing & Using portdowngrade

cd /usr/ports/*/portdowngrade
make DEFAULT_CVS_SERVER=\":pserver:anoncvs@anoncvs.tw.freebsd.org:/home/ncvs\" install clean

Note that you may replace the server name with whichever mirror you chose in the earlier step.

Once installed, you may now downgrade the port using:

portdowngrade devel/bugzilla

for instance. From here the documentation will be more than enough to show you how to get the downgraded port checked out and installed.

The Missing Step: Making portupgrade Ignore the Port!

This is easy as pie, but there are two ways to do it. I chose to do both.

Option 1: Edit the pkgtools.conf file

Usually located in /usr/local/etc/, pkgtools.conf will allow you to specify an additional port in the HOLD_PKGS array like such:

HOLD_PKGS = [
    'bsdpan-*',
    'devel/bugzilla*'
]

Option 2: +IGNOREME

Creating a +IGNOREME file in the package directory will stop both portaudit and portmaster from upgrading the port.

touch /var/db/pkg/bugzilla/+IGNOREME

In a recent battle at work I put a Cisco 2960G up against a Dell PowerConnect 5424. The PowerConnects aren’t bad… They’re cheap, gigabit, and Layer-2. Anyway, I quickly found out that unless you use GVRP, the Dell cannot learn what VLANs are out there. You have to specify allowed VLANS specifically on both ends of a trunk.

The Cisco 2960G doesn’t support GVRP, and VTP is proprietary, so I was forced to use this method.

On the Cisco:

switchport mode trunk
switchport trunk allowed vlan add 2,100,101
switchport nonegotiate

On the Dell:

switchport mode trunk
switchport trunk allowed vlan add 2,100,101

/etc/rc.d/named: WARNING: devfs_domount(): Unable to mount devfs on /var/named/dev
devfs rule: ioctl DEVFSIO_RAPPLY: Operation not permitted
devfs rule: ioctl DEVFSIO_RAPPLY: Operation not permitted

The reason for this is that by default in FreeBSD named tries to run within a chroot. The chroot for named requires /dev/zero, and /dev/random, so the rc script that starts named tries to mount a devfs for named. The problem is that jails cannot mount, for obvious reasons.

The quick solution is to tell FreeBSD not to try to run named within a chroot. The idea is that a jail is good enough. You can do this by seting:

named_chrootdir=""

within the JAIL’S /etc/rc.conf.

The other option is to create the chroot dir for named from the host system for the jail before you start it. This really doesn’t have too much of a benefit. But it’s possible by issuing the following commands from the host system for your jail:

# mount -t devfs devfs /jails/jailhost.whatever.com/var/named/dev/
# devfs -m /jails/jailhost.whatever.com/var/named/dev/ rule -s 1 applyset
# devfs -m /jails/jailhost.whatever.com/var/named/dev/ rule apply path null unhide
# devfs -m /jails/jailhost.whatever.com/var/named/dev/ rule apply path random unhide

Once you’ve done that, you can start named in the jail, and you’ll have named running inside a chroot within a jail. This doesn’t quell the error messages, but you can trust that they’re irrelevant, or if you feel like it, you can patch /etc/rc.d/named within the jail to not try to create/destroy chroots. Find these lines of code:

# Mount a devfs in the chroot directory if needed
#
umount ${named_chrootdir}/dev 2>/dev/null
devfs_domount ${named_chrootdir}/dev devfsrules_hide_all
devfs -m ${named_chrootdir}/dev rule apply path null unhide
devfs -m ${named_chrootdir}/dev rule apply path random unhide

and make them look like this:

# Mount a devfs in the chroot directory if needed
#
#umount ${named_chrootdir}/dev 2>/dev/null
#devfs_domount ${named_chrootdir}/dev devfsrules_hide_all
#devfs -m ${named_chrootdir}/dev rule apply path null unhide
#devfs -m ${named_chrootdir}/dev rule apply path random unhide

Now you have to maintain this stupidity, if your mergemaster changes /etc/rc.d/named, but I guess it’s nice not to see errors. You also can’t start your jails automatically at boot, because the chroot won’t exist yet… So…. whatever.

READ THIS TOO: http://www.irssi.org/documentation/startup#c3

Step 1: The Final Solution

Since you’ve probably configured irssi incorrectly, the first thing you should do is log into your shell on whatever server you’re using screen+irssi from and do:

rm -rf ~/.irssi

What this will do is blow away any crappy settings you’ve got going. Since whoever configured your irssi probably didn’t care to do a good job on your instance, this is probably best.

Step 2: Configure irssi

Start irssi:

irssi

At the nice clean irssi window, type the following commands:

/network add VoidNet
/server add -auto -network VoidNet irc.easymac.org
/channel add -auto #VoidNet VoidNet [password]
/save
/quit

If you’re not an idiot you can probably figure that if the channel doesn’t have a password, you don’t need to specify the [password] part. If it does, then… well… you get the idea.

Step 3: Start, Name, Attach, and Detach Your Screen

The only functions you really need to know are screen creation, screen detaching, and screen attaching. They’re quite simple, but for some reason people who don’t know how to use screen like to create screens where they should be attaching existing screens.

So, the first thing you need to do is learn what screens are running!

screen -ls

If you see something like:

screen -ls
No Sockets found in /tmp/screens/S-username.

You’re in good shape. Otherwise, the action necessary is out of the scope of this document. Have fun.

Continuing on…. Let’s start a new screen, named IRC for the purpose of…. IRC!

screen -S irc irssi

OMG irssi is now running inside a screen named irc, wonderful!

To detach, but leave the screen running you need to do a keystroke. (ctrl+shift+a,d)

To reattach the screen simply do:

screen -rd irc

Yay, your irssi is good!

Step 4: Starting irssi At Server Reboot

You don’t NEED to do this step, but there’s nothing more annoying then when irssi isn’t started because the admin was a jerk and rebooted the server. So if you want to avoid that annoyance, it’s quite simple to do.

Edit your crontab using:

crontab -e

and insert this line:

@reboot     screen -d -m -S irc irssi

Either way, there’s a quick & easy way to try to stop these annoying bots or whatever they are from bugging your server with PF.  Basically, on your rule where you pass SSH connections in through the firewall you can set a ‘max-src-conn-rate’ or maximum source connection rate.  What this does is triggers something to happen when a host connects faster than a certain rate of allowed new connections.  In our case we’ll want to dump these users into a table that blocks everything from them.  So we create the table:

table <ssh-bruteforce> persist

The rule to drop people who are clearly spamming into our ssh-bruteforce table is:

pass in on $ext_if inet proto tcp from any to any port ssh flags S/SA keep state (max-src-conn-rate 4/30, overload <ssh-bruteforce> flush global)

Where the connection rate is 4 connections in 30 seconds (4/30).  From this point on, you just want to block them.  You can do that with:

block in log quick on $ext_if from <ssh-bruteforce>

Now anybody who tries to esablish connections faster than the rate specified in the pass rule gets dumped into that table, and blocked from accessing anything at all on your server. 

mhoran++