====== Technical Information: General FreeBSD Topics ====== ===== Installation Practices/Solutions ===== ==== Resolve issue with boot device not found ... ==== 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'' ...// ==== Typical Packages to Install ==== * pdksh * sudo * vim * htop * screen * rsync * wget * git * irssi * mutt * twm * xterm * tightvnc * terminator ==== Typical Firewall ==== 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 { 24.159.210.154,24.159.210.156,24.159.210.157 } block all pass in proto tcp from 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 ===== Misc Tech Trivia ===== === Add a route ... === 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 === CPU Info === sysctl -a | egrep 'hw.machine|hw.model|hw.ncpu' ===== Application-Specific Trivia ===== ==== bitlbee ==== === Configuring bitlbee under FreeBSD=== * 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. === Launch bitlbee from inetd(8) === Add the following line to ''/etc/inetd.conf'' and reload inetd(8): ircd stream tcp nowait bitlbee /usr/local/sbin/bitlbee bitlbee -I === Launch bitlbee as a daemon === Add the following line to ''/etc/rc.conf'': bitlbee_enable="YES" === OTR-related settings === * **''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 smpq1 <@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 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:start|Tech Info]] ... [[:mantis:start|Mantis Area]] //