This blog entry by Michael W. Lucas, has got to be one of the most impressive ways I’ve ever heard, for integrating OpenBSD in a hurry.

Marc Espie on portability

Marc Espie on portability: “
A short while ago, Marc Espie (espie@) wrote to the ports mailinglist with a short rant about autoconf. His mail gives good insights into the problems porters face when dealing with GNU software, especially those using autoconf.”

This actually describes one of the many reasons I despise working a lot of other ‘programmers’ in this world, many of whom exhibit even greater levels of brain injury then that post takes as examples.
In my not so humble opinion: GNU autotools is either a good idea gone horrible wrong (in practice), or a royal brain fuck that just got out of hand. Users who can use such tools properly, seem to be falling by attrition to younger developers, many of whom (in my experinces anyway) wouldn’t know portability if it strung them on the keester like sitting on a scorpion. The GNU build system can an extremely good tool chain to work with, or it can be your worst freaking nightmare; a lot of people just don’t seem to care any more. My policy has always been, to support what I use (BSD/Win), and trying to minimise the heartache of getting code built on another platform.
Although the GNU project is perhaps the largest distributor of infectious disease on the Internet, I blame the developer idiocy I see around me, on the youth and not on the software. Most “Old wizards” seem to actually know their tools…..

Mario: Treat your tools like a friend. Keep ’em by you. Never let ’em down, and they’re always at your side.

Luigi: Hey, Mario, how is it that for every situation that could possibly come up, you always got a saying about tools? 

Mario: I got ’em from Papa. 

Both: He got ’em from Grandpapa!

Haha, believe it or not but I just upgraded my file server from OpenBSD 4.4 Release to OpenBSD 4.5 Release, lol. Usually I’m pretty good about keeping my systems up to date, but lately life has just been to troublesome to care about it :-/.

In a change, I’ve also elected this time to install the various X related dist sets in the upgrade; I have no need to run GUI tools to manage my file server, but I have been thinking of using the machine to supplement my laptop, by way of running an X-Server on the desktop machine, and employing SSH for an extra layer of encryption.

Although I have never had need of (nor desire to try) the OpenBSD ports system, it does require X if memory serves, so probably good to have it available. Since the box isn’t setup for running an X server it is only filling free diskspace, and that box is well partitioned hehe.

14 months from purchase to setup?

Not so long ago a thread came up on DF, dealing with printing. That reminded me…. I baught my printer in what, February of 2007 and it’s just been gathering dust?

That’s gotta be a new record: for either laziness or being to fsckin’ busy lol.

The reason I bought it, I knew this model was usable with most OSes. Honestly, I _hate_ ink jet printers (and printers in general, but yeah… especially ink jets). Sadly, a decent PostScript printer is harder to find in this place then an affordable laser printer; having to use an inkjet makes me very happy that I rarely print anything.

Around OpenBSD 4.3 or so, I stripped off all printing related packages off my server: the shitmark hasn’t worked in years. So I had to setup the format filtering magic anew: ghostscript (no_x11 flavour), hpijs, foomatic-filters, and foomatic-db-hpijs. Several years ago it was my intention to run a networked printer off the box, but the printer I had at the time more or less stopped functioning under FreeBSD+CUPS, so I haven’t paid much attention since then. Most distributions use the Common Unix Print System (CUPS) these days; but I’m just old at heart, I like the Berkeley Line Printer Daemon (lpd). CUPS, only way I ever know wth is going on is going cross eyed with log files; with lpd, at least you know it’s brainlessly simple to sort out.

My only complaint about the printer, ‘lptest | lpr’ resulted in 2 pages of ~60 lines before I decided to dequeue the 200 line job: and the some-bitch isn’t smart enough to eject the darn 3rd sheet of paper ^_^. (whether this has to do with my PPD file or hpijs support for my printer is not interesting to me, lol). On top of that, the thing prints about as slow as I can write text by hand. I could just imagine if I fed tpsh’s ~3000 lines of text though it, probably take a week and 50 sheets of paper.

Strange behavior with this bit of C++

It has been a long time since I’ve had time to do anything in C++. So I figured it would be a useful way to limber up my memory, by implementing a little bit of my favorite Python classes/modules in C++. The only crazy thing, is the result this code has yielded.

// minimal program, using the code involved
#include
#include

extern "C" {
#include <sys/param.h>
#include <unistd.h>
}

namespace os {
bool link(const std::string& src, const std::string& dst);
}

bool
os::link(const std::string& src, const std::string& dst) {
if (link(src.c_str(), dst.c_str()) != 0) {
std::perror(NULL);
return false;
}
return true;
}

int
main() {
std::cout << "link()t" << std::endl;
os::link(std::string("./test"), std::string("/tmp/test"));
return 0;
}

compilation: /usr/bin/g++ -Wall -ggdb3 os.cpp test.cpp -o test

I compiled on FreeBSD 7 with the systems GCC 4.3.1 and get a segfault, then tried the code on my OpenBSD 4.4 machine. The OpenBSD 4.4 release has shipped with a patched GCC 3.5.3 (propolice) – on OpenBSD it ran perfectly! Trying to feed it through the debuger on FreeBSD wasn’t pretty either:

  • FreeBSD 7, system GCC 4.3.1 -> test program dies with a Segmentation Fault.
  • FreeBSD 7, system GDB 6.1.1 -> Endless stepping when used with a break point, or SIG SEGV in libc’s malloc() when run.
  • OpenBSD 4.4, system GCC 3.5.3 -> prints proper message from std::perror() as expected, when the program is executed.

If I change os::link to os::link_x and recompile on FreeBSD, it works the same as it does on OpenBSD, when unmodified that is. In a few tests on FreeBSD, When I run the program under GCC, it tells me

Program received signal SIGSEGV, Segmentation fault.
0x281fabc3 in malloc () from /lib/libc.so.7

if I set a break point in test.cpp on the os::link() call, and step through it into os::link() in os.cpp. If I keep stepping after the link(), I get returned to the os::link() call in main and can step through it all again. Like an endless loop of stepping into/out of the os::link() function call in test.cpp’s main(), and the if-conditional in os.cpp’s os::link(), geeze.

At least looking at the results I’ve had tonight, I know I’m not freaking nuts… lol. I still shouldn’t write code when I’m half asleep, but hey… It’s the only time I get :, Oh well… unless my family is late as usual, I need to be up in a few hour.

*head hits laptop, snores loudly until morning*

running off the deepend

Well, finished one portion of my docs (Grrr… wasting time in #kde-chat and #vim lol); even got one of the manual pages written out.

Ya know, with the mdoc.samples(7) and mdoc(7) manual pages + a few simple manual pages for reference (head, cat, pkg_add) the process of writing a manual page is actually much less painful then I remember it being. I’ve only got one small problem so far, thin I’ll post on daemonforums later and see if anyone has an idea; if not I’ll probably have to adjust the man pages wording a lit’ bit.

nroff/troff is also strangely addicting once you start playing with macro packages…

Muahuaha !!! I love this thing.

$ vim pf.conf.new
... write new packet filter configuration file
$ pfctl -nf pf.conf.new
... silent output if no errors
$ su - root
Password:
# cd /etc
# mv pf.conf pf.conf.old
# cp /home/Terry/pf.conf.new /etc/pf.conf && rm /home/Terry/pf.conf.new
# chmod 644 pf.conf && chown root:wheel pf.conf
# echo 'pfctl -F all -d' | at hhmm
... unlock the door if we screw up
# pfctl -e

enabling or disabling the packet filter (-e, -d) kills the SSH connection, but in the event of any embarrassing “oh crap, I’ve locked myself out” accidents, the at job will flush the firewalls settings and disable it. Believe me, if you’ve got a system running with no head or physical inputs (e.g. no monitor, no keyboard), ya really want to use such a thing… I still remember coming home from a *very* bad day at work, working on my rule sets, and locking myself out 5 times, and having to hook up a monitor and keyboard to the server each time >_>.

What wonders you can learn from one bad day, huh?

At least tonight, I’ve not locked myself out once… despite the days troubles, hehe. One of the reasons I like OpenBSDs packet filter, it’s simple, it’s powerful, just read the fine manual, use your gray matter, and it works! The rule sets are fairly easy to read, and OpenBSD documentation is second to none. Heck the manual page even gives the pf.conf syntax in Backus-Naur Form. The only complex part of pf, is the networking stuff – not the configuration. And of course, I love anything that is configured through a sane text file, rather then having to fire up some cornball program lol. Really, I wish I had the resources to replace my router with an OpenBSD machine, that way I wouldn’t have to learn my way around a new web-interface whenever one pops its final cork.

Ahh… At least one good thing happened this weekend!!!

Wireless networking options

I’m contemplating *trying* to move my desktop PC to my room… Which means access to the ‘net will only by available via wireless. The computer doens’t have a wirfi card, just ethernet so that means shopping is involved.

It primarily runs Windows XP for gaming and has space reserved for testing GNU/Linux distros and BSD systems. Being a BSD-aware and manual reading shopper, I always crack open my operating systems manuals and look at what cards are supported by the drivers when I go looking for a product.

Since the only principal markets available to me off the web are Best Buy and Office Depot, those are where I looked online first.

The cards:

NETGEAR – 802.11g PCI Card Model: WG311

Pro’s:
Supported by ath drivers.

Same brand and chipset as my PCMCIA card (WG511T)

Con’s:

Old (or cheap) product, only supports WEP (which I don’t use)

Newer revisions may not be totally compatible with existing drivers (I suspect).

Belkin – Wireless-G USB 2.0 Network Adapter, Model: F5D7050

Pro’s:

Version 3 is supported by the rum driver and v2000 by the ral driver.

Con’s:

Reviews suggest bad gaming performance due to burst based transmissions

The rum driver is new to FreeBSD 7.0-Release (ported from OpenBSD)

GOD only knows what revision/version you might find at the store…

Hawking Technology – Wireless-G USB 2.0 Network Adapter,
Model: HWUG1 at best buy and at OfficeDepot

Pro’s:
Supported by the rum

Removable aerial and possibly good signal strength if you don’t have problems with it.

Con’s:

The rum driver is new to FreeBSD 7.0-Release (ported from OpenBSD)

May be hard to find (lesser known brand, at least from what I’ve seen of consumer (non enterprise) products).

Just look at Hawking Technologies website… (ugh)

Linksys Wireless-G 802.11g PCI Adapter, Model WMP54G at Office Depot and Best Buy

Pro’s:

Supported by the ral driver.

It’s cheap

It’s available while it is still on the market

It’s the same brand as my router (which is _not_ a plus in my book…)

Con’s:

More stores are carrying similar but newer models for Wireless-N and variants of the both (802.11g and 802.11g/n) proprietary speed boosting technology, which of course is unsupported.

It’s the same brand as my router (which I don’t care much for!)

MISC:

Driver support on OpenBSD and FreeBSD at release levels…

ath == OpenBSD 3.7, FreeBSD 5.2, NetBSD 2.0 (more recent modules don’t use a binary blob, at least the OpenBSD drivers that is (-;)

ral == OpenBSD 3.7, FreeBSD 6.0 and may require PCI 2.2 compatible mother boards.

rum == OpenBSD 4.0, FreeBSD 7.0

ural == OpenBSD 3.7, FreeBSD 6.0 and may have issues with communicating transmission speed (OBSD manual is more specific).

All of this is posted for my own reference and anyone else who may find use for it.

Adding MySQL to my OpenBSD machine

My best friend while doing all of this was the MySQL Reference Manual :-).

The hard part was the fact that this and every thing else I want setup should have been done like 6 or 7 hours ago… But that’s my family for ya….

Phase I: Install and Configure the MySQL database service:

My desktop has WAMP installed and a mother load of development tools, my PC-BSD
laptop has the most complete development environment I have access to, and is
where I do all of my real work ^_^.

In order to make some progress in a few bits of playful testing and work that I
do need to tinker with, I’ve elected to setup things on Vectra to avoid the more
transient nature of the Windows machine here…

This is the notes I’ve compiled during the process. Managing to sleep off the
headache and get this done before everyone else wakes up… Grr. The machines an
OpenBSD 4.3-Release system working off an old Pentium 3 500Mhz with 384MB of RAM
— far from ideal for running MySQL but with just me to play with it, it’s no
problemo.

ssh2v
...
su - root
Password:

pkg_add -iv mysql-server
less /usr/local/share/doc/mysql/README.OpenBSD # refer to the instructions
given

vi /etc/login.conf
... # let the login class for _mysql and rebuild the login database
cap_mkdb /etc/login.conf
/usr/local/bin/mysql_install_db
... # initialize the database files
vi /etc/rc.mysql
... # quick script to launch mysql properly, listing 2A
vi /etc/rc.local
... # start it during resource configuration, listing 2B
/etc/rc.mysql
/usr/local/bin/mysql_secure_installation
... # secure the installation := -u root -p (pw=V1p3l2)
mysqladmin -u root -p status
...
mysql -u root -p -h localhost # set up our databases using the mysql client
Enter password:
Welcome to the MySQL monitor. Commands end with ; or g.
Your MySQL connection id is 18
Server version: 5.0.51a-log OpenBSD port: mysql-server-5.0.51a

Type 'help;' or 'h' for help. Type 'c' to clear the buffer.

mysql> CREATE USER trowa IDENTIFIED BY '*********';
Query OK, 0 rows affected (0.03 sec)

mysql> CREATE DATABASE SpidersWeb
-> ;
Query OK, 1 row affected (0.01 sec)

mysql> SHOW DATABASES;
+--------------------+
| Database |
+--------------------+
| information_schema |
| SpidersWeb |
| mysql |
+--------------------+
3 rows in set (0.00 sec)

mysql> GRANT ALTER, ALTER ROUTINE, CREATE, CREATE ROUTINE, DELETE, DROP,
-> EXECUTE, INDEX, INSERT, LOCK TABLES, SELECT, CREATE VIEW, SHOW VIEW,
-> UPDATE ON SpidersWeb.* TO 'trowa'@'%';
Query OK, 0 rows affected
mysql> exit
Bye

That basically allows the database user to do just about everything to the
specified database from anywhere. I considered restricting access further but am
not in the mood to screw with changing it later should it become necessary (and
I hate setting up replacement routers, which happens every now and then).

Since every thing in the mysql client ends up in ~/.mysql_history, including the
password used in the CREATE USER statement. I am also rather glad that OpenBSD
keeps everyones nose out of /root by default, I plan on shredding the file:

rm -P /root/.mysql_history

for safety.

Phase II: Verify it works!

To make sure every thing works out properly enough (considering the current
local time!). I opened another urxvt on my laptop and connected to the server
machine.

Terry@dixie$ mysql -h vectra -u trowa -p SpidersWeb                        5:44
Enter password:
Welcome to the MySQL monitor. Commands end with ; or g.
Your MySQL connection id is 22
Server version: 5.0.51a-log OpenBSD port: mysql-server-5.0.51a

Type 'help;' or 'h' for help. Type 'c' to clear the buffer.

mysql> SHOW TABLES
-> ;
Empty set (0.01 sec)

mysql> exit
Bye
Terry@dixie$ 5:45

Various notes

I found the kern.maxfiles sysctl and standard issue /etc/my.cnf file suitable
for my needs (for now). So no need to screw with them tonight, later on I need
to work on setting up httpd and things… Already 0600Z and work is early
tomorrow so no time to sor that out

Rather then muck about, in case I need to stop and start mysqld I moved the
startup from /etc/rc.local to calling a shell script to run it properly. That
way OpenBSD should allow mysqld sufficant file handles and I can control things
via /etc/my.cnf if I wish to lower it.

Listing 1: /etc/login.conf

#
# This class is used when running MySQL from /etc/rc.local
# XXX: It will *N_O_T* be used when starting/stopping mysqld manually!!
#
_mysql:
:ignorenologin:
:datasize=infinity:
:maxproc=infinity:
:openfiles=3580: # I've set this to sysctl::kern.maxfiles
:stacksize-cur=8M:
:localcipher=blowfish,8:
:tc=daemon:

Listing 2A: /etc/rc.mysql

#!/bin/sh
#
# A simple script to launch mysqld with the proper login privledges
#

su -c _mysql root -c '/usr/local/bin/mysqld_safe >/dev/null 2>&1 &'
echo -n ' mysql

Listing 2B: edits to /etc/rc.local

# launch the MySQL database server
if [ -x /usr/local/bin/mysqld_safe -a -x /etc/rc.mysql ]; then
/etc/rc.mysql
fi

Fixing last nights screwups

Well this is what happens when your working around 0400 local time :

After last nights double upgrades my system wouldn’t except my login over ssh citing an invalid password (when it was correct!). Plus it was refus8ing connections on the port I have sshd listing to but accepting on the default port 22, even though I merged my sshd_config with the new one.

Hooked up a monitor and keyboard to the server and even root was being rejected. I know I forgot to run /dev/MAKEDEV before rebooting the kernel but if that had any problems either init, rc, or getty would be dying from problems setting up TTYs and mounting disks!

Booted off the install floppy I had left over from the 4.0 upgrade and dropped to shell. Since I had to did a rude shutdown when I realized what was up, I had to force the mounts before I could go to work. Then I change rooted into the servers file system to get to fixing the login problem.

mount -f /dev/wd0a /mnt
mount -f /dev/wd0g /mnt/usr
chroot -u root /mnt sh

I knew I forgot to make the new device nodes so I did that and took a look at /etc/group and /etc/passwd before touching any thing else.

/dev/MAKEDEV all
TERM=vt220 vi /etc/group
...

I had to set TERM for nvi because with an empty $TERM after the chroot operation, vi couldn’t handle the situation :

checked out the group file and noted my custom user groups were missing, changed files :e /etc/passwd and noted that my user account was also missing!

Made a fix of this:

group add -g 7778 nfsusers
adduser
...

Added the nfsusers group for the file shares and recreated my personal user before mounting /home. That gave me enough that I could reboot, strip monitor and keyboard, and SSH into it from the desktop to finish poking around.

On login my shell prompt was ‘Terry@noname-$ ‘ and I know my ksh prompts are ‘username@hostname-$ ‘ which means my systems hostname settings were nuked.

Lo and behold, it hit my like a bus.

During last nights upgrade I remembered specifically that I did remove etc42.tgz in /usr/obj/4.2 before using a for loop to extract all of the file sets. But I could not remember doing the same with etc43.tgz in /usr/obj/4.3 when I installed the last file sets :

Sure enough I looked in both directories and last nights log and bingo that is what happened! I ended up extracting the default configuration files for OpenBSD 4.3 after my upgrade.

I didn’t take a backup of /etc before hand because I knew it wouldn’t be harmed, assuming I didn’t fsck things up. And of course any thing irreplaceable is backed up in like 4 or 5 places any way.

It looks like the only major losses in /etc were exports which I rewrote simply. I copied the %ProgramFiles%etcgroup file to the server as /etc/group.old and used vimdiff to merge my other custom groups in before moving on.

rc.local was overwritten but that’s no loss because everything I had in there was commented out and there depends got pkg_delete’d last night 😉

I repaired /etc/hosts, checking my changes against the hosts file on my desktop, (%WinDir%system32driversetchosts). Each of my machines defines a couple of ‘quick’ items in hosts. Then fixed /etc/myname with my machines proper name.

the settings in /etc/ntpd.conf were overwritten but unused for ages, the patch operations also left me my original file as /etc/ntpd.conf.orig hehe and I cleaned the rest out

cp /etc/ntpd.conf.orig /etc/ntpd.conf.ORIG
rm /etc/*.orig

Then set to fixing ssh_config and sshd_config

cd /etc/ssh && vim .

This really is what I get for doing things so late at night +S