gpart show
gpart set -a active /dev/ada0
gpart set -a bootme -i 3 /dev/ada0

… 3 was the number of my boot partition as seen in gpart show …

• pdksh
• sudo
• vim
• htop
• screen
• rsync
• wget
• git
• irssi
• mutt
• twm
• xterm
• tightvnc
• terminator

To re-read the firewall rules: pfctl -f /etc/pf.conf
In /etc/pf.conf:

# SSH, DNS, HTTP, HTTPS, IRC, Murmur
tcp_pass = "{ 22 53 80 443 7000 64738 }"
# DNS, XDMCP, Murmur
udp_pass = "{ 53 177 64738 }"
# SSH tunnels
tcp_ssh = "{ 12224 22012 }"
# Bitlbee and Eggdrop
tcp_irc = "{ 6667 7667 }"
# VNC
tcp_vnc = "{ 5800:5801 5900:5901 6000:6001 }"
table <emailers> { 24.159.210.154,24.159.210.156,24.159.210.157 }
block all
pass in proto tcp from <emailers> to port 25 keep state
pass in proto tcp to port $tcp_pass keep state
pass in proto udp to port $udp_pass keep state
pass in from 192.168.0.0/24
pass out all 

route add -net 192.168.2.0/24 192.168.1.2

… or …

route add -net 192.168.0.0/24 24.159.210.154

sysctl -a | egrep 'hw.machine|hw.model|hw.ncpu'

• Copy /usr/local/share/examples/bitlbee/bitlbee.conf to /usr/local/etc/bitlbee/bitlbee.conf
• Copy /usr/local/share/examples/bitlbee/motd.txt to /usr/local/etc/bitlbee/motd.txt
• … modify both to suit local details.

You have two options for launching bitlbee: either launch it from inetd(8) or run it as a stand-alone daemon.

Add the following line to /etc/inetd.conf and reload inetd(8):

ircd            stream  tcp     nowait  bitlbee /usr/local/sbin/bitlbee bitlbee -I

Add the following line to /etc/rc.conf:

bitlbee_enable="YES"

• otr_policy
  Possible values: never, opportunistic, manual, always
  This setting controls the policy for establishing Off-the-Record connections. See the next section for details.

• otr_color_encrypted
  Possible values: true, false
  If set to true, BitlBee will color incoming encrypted messages according to their fingerprint trust level: untrusted=red, trusted=green.

• otr_does_html
  based on ticket#690 this “causes OTR plaintext to always be considered HTML.”
  Even though the spec defines that HTML markup is optional (Data Message section) in practice OTR messages are HTML messages for most (if not all) clients.

• OTR policies
  never: disables the OTR subsystem.
  opportunistic: A magic whitespace pattern will be appended to the first message sent to any user. If the peer is also running opportunistic OTR, an encrypted connection will be set up automatically.
  manual: OTR connections must be established explicitly using otr connect.
  always: enforces encrypted communication by causing BitlBee to refuse to send any cleartext messages at all.

The “magic whitespace pattern” that opportunistic OTR uses consists of 16-40 bytes of either space or tab characters (See the “Tagged plaintext messages” section of the OTR spec for more details). This might cause minor visual issues in some IM clients.

• Simple Question and Answer Response
  You can authenticate a user's fingerprint by asking a question using the otr smpq

  1 <@alice> otr connect bob
  2 <@alice> otr smpq bob "question question question" answer
  3 <@root> smp: initiating with bob...

• On the other side:

  1 <@root> smp: initiated by alice with question: "question question question"
  2 <@root> smp: respond with otr smp alice <answer>
  3 <@bob> otr smp alice answer
  4 <@root> smp: responding to alice...
  5 <@root> smp alice: secrets proved equal, fingerprint trusted

• Issues
  • OTR does NOT work (well) with offline messages.
  • Without previous or future chat-session, offline messages from either party will not be passed on and no notification will be sent. OTR messages are only being delivered in these scenarios:
    • User “A” and “B” are in an OTR session, when “B” is disconnecting. Messages from “A” are being delivered after “B” reconnects.
    • User “A” is attempting an OTR session with the offline-user “B”, when “B” is connecting while “A” is still online.

Links: Tech Info … Mantis Area