Monthly Archives: December 2014

Debian Wheezy i386 in FreeBSD’s bhyve

Just managed to install a Debian Wheezy i386 in the FreeBSD’s bhyve, after a failed attempts with Fedora 21 server and openSuSE 13.2. Also, grub2-bhyve wasn’t reliable until I changed the arch to i386, and the type of medium to “netinstall” – that got it rolling.

One warning – the video is uncut, and thus suffers from a few half-minute gaps during the installation.

The FreeBSD used is FreeBSD 11.0-CURRENT amd64, because at the moment bhyve is functional for AMD CPUs only in CURRENT. Continue reading

Positive, comparative, and the code used in a linux

I read a thread where OpenBSD community were discussing the code for the network time daemon, and some figures stated there seemed almost unreal. Out of the pure curiosity, that has nothing to do with deeper understanding of the ntp daemon code, I ran “a test” used there on an OpenBSD, a FreeBSD and a Linux machine. The results are truly staggering:

uname -rms ; pwd ; for i in $(find . -name “*.[ch]”); do cat $i >> allcode; done ; egrep -v ‘[:blank:]*/?\*’ allcode | grep -v “^ *$” | wc -l
OpenBSD 5.6 amd64
/usr/src/usr.sbin/ntpd
2898

uname -rms ; pwd ; for i in $(find . -name “*.[ch]”); do cat $i >> allcode; done ; egrep -v ‘[:blank:]*/?\*’ allcode | grep -v “^ *$” | wc -l
FreeBSD 11.0-CURRENT amd64
/usr/src/contrib/ntp/ntpd
40055

uname -rms ; pwd ; for i in $(find . -name “*.[ch]”); do cat $i >> allcode; done ; egrep -v ‘[[:blank:]]*/?\*’ allcode | grep -v “^ *$” | wc -l
Linux 3.17.6-200.fc20.x86_64 x86_64
/tmp/ntp-4.2.8/ntpd
102214

Project OpenBSD proved itself time and again as a proper place if you want to learn coding!

Wake-on-LAN a FreeBSD server

Compiled from at least three sources of wisdom, here is a brief wake-on-lan note for FreeBSD 10.1-STABLE.

Set your BIOS first, mine is tuned in “Advanced >> APM >> Power On By PME”!

Next, check your NIC:

# grep -l IFCAP_WOL /usr/src/sys/dev/*/*.c
/usr/src/sys/dev/ae/if_ae.c
/usr/src/sys/dev/age/if_age.c
/usr/src/sys/dev/alc/if_alc.c
/usr/src/sys/dev/ale/if_ale.c
/usr/src/sys/dev/bxe/bxe.c
/usr/src/sys/dev/e1000/if_em.c
/usr/src/sys/dev/e1000/if_lem.c
/usr/src/sys/dev/fxp/if_fxp.c
/usr/src/sys/dev/jme/if_jme.c
/usr/src/sys/dev/nfe/if_nfe.c
/usr/src/sys/dev/nge/if_nge.c
/usr/src/sys/dev/re/if_re.c
/usr/src/sys/dev/sis/if_sis.c
/usr/src/sys/dev/ste/if_ste.c
/usr/src/sys/dev/stge/if_stge.c
/usr/src/sys/dev/txp/if_txp.c
/usr/src/sys/dev/vge/if_vge.c
/usr/src/sys/dev/vr/if_vr.c
/usr/src/sys/dev/xl/if_xl.c

Continue reading

If php-fastcgi won’t come to the IP:port, the socket will come to the php-fastcgi

I’ve had an unusual problem with lighttpd-1.4.35p2-ldap-mysql and php-fastcgi-5.4.30 on an OpenBSD 5.6 amd64: php-fastcgi-5.4.30 was refusing to use/bind to an otherwise perfectly available address and port no matter what, with similar to the following in the logs:

(mod_fastcgi.c.984) bind failed for: tcp:192.168.100.32:9000 Can’t assign requested address

That was ridiculous, because

a) none of the methods would give even a smallest hint that the IP and port were somehow and somewhere in use,
b) changing the IP, the port, or any other parameter for the server.bind, server.port, or the fastcgi.server section would make a difference – exactly the same message would emerge again in the log, only with the new parameters.

The socket, though, works just fine, so, in order to stop spending time on debugging of such a bizarre behaviour, I simply switched to the socket method.

However, I’d really like to read an explanation for this particular mystery. Any ideas? Or I simply have to start somewhere before the line 984 of the mod_fastcgi.c?

Mediawiki in chroot – php in hell

Setting Mediawiki’s LDAP authentication and mail functionality while it is running in an OpenBSD’s nginx chroot took some time to debug and prepare.

As always, the first thing should be the set-up of a log:

$wgDebugLogFile = “../logs/mediawiki/debug-{$wgDBname}.log”;
error_reporting( -1 );
ini_set( ‘display_errors’, 1 );

Continue reading

dbus and GNOME 3.14.2 on FreeBSD 11 CURRENT

There was an update of GNOME3 for FreeBSD 11 CURRENT, and now it is 3.14.2 instead of 3.14.0. The package that can really make a difference after this update is dbus – if left in rc.conf the way it ran in GNOME2 days, similar to this:

devfs_system_ruleset=”localrules”
#dbus_enable=”YES”
#hald_enable=”YES”
#avahi_daemon_enable=”YES”
#avahi_dnsconfd_enable=”YES”
gnome_enable=”YES”
tor_enable=”YES”

it will freeze the boot, and your console will be spammed with the race conditioned messages from dbus, so much that you will think that FreeBSD just switched to systemd, too 🙂

Simply abandon the old ways, and let a single “gnome_enable=YES” in the /etc/rc.conf take care about all of the dependencies it requires.

GNOME 3.14.0 did ignore it well, GNOME 3.14.2 does not forgive it in the rc.conf.