Upgrading cyrus-sasl-saslauthd-2.1.25 to the current cyrus-sasl-saslauthd-2.1.26, I started to get auth_krb5.c compile errors that were terminating the compile like:
<command-line>: warning: this is the location of the previous definition mv -f .deps/auth_getpwent.Tpo .deps/auth_getpwent.Po cc -DHAVE_CONFIG_H -DSASLAUTHD_CONF_FILE_DEFAULT=\"/usr/local/etc/saslauthd.conf\" -I. -I. -I.. -I. -I./include -I./include -I./../include -I/usr/local/include -DKRB5_HEIMDAL -I/usr/local/include -O3 -pipe -march=native -DLDAP_DEPRECATED -fno-strict-aliasing -MT auth_krb5.o -MD -MP -MF .deps/auth_krb5.Tpo -c -o auth_krb5.o auth_krb5.c In file included from mechanisms.h:35, from auth_krb5.c:51: saslauthd.h:190:1: warning: "KRB5_HEIMDAL" redefined <command-line>: warning: this is the location of the previous definition auth_krb5.c: In function 'auth_krb5_init': auth_krb5.c:105: warning: assignment discards qualifiers from pointer target type auth_krb5.c:106: warning: assignment discards qualifiers from pointer target type auth_krb5.c: In function 'auth_krb5': auth_krb5.c:184: error: 'krb5_verify_opt' undeclared (first use in this function) auth_krb5.c:184: error: (Each undeclared identifier is reported only once auth_krb5.c:184: error: for each function it appears in.) auth_krb5.c:184: error: expected ';' before 'opt' auth_krb5.c:233: error: 'opt' undeclared (first use in this function) *** Error code 1 Stop in /usr/ports/security/cyrus-sasl2-saslauthd/work/cyrus-sasl-2.1.26/saslauthd. *** Error code 1 Stop in /usr/ports/security/cyrus-sasl2-saslauthd/work/cyrus-sasl-2.1.26/saslauthd. *** Error code 1 Stop in /usr/ports/security/cyrus-sasl2-saslauthd.
with some expert advice from the port maintainer, Hajimu UMEMOTO (what is not to love about BSD and open source? Something goes wrong, the guy who knows everything about it tells you how to fix it right away). He correctly ascertained that I had
security/krb5 installed, a dependency of
openssh-portable. Kerberos, HEIMDAL and GSSAPI occasionally have interactions, but his advice was to make with the directive
KRB5_HOME=/usr/local. I put this into
/etc/make.conf to make it permanent, deinstall/reinstalled
security/krb5 and then
cyrus-sasl-2.1.26 compiled perfectly.
Thanks Mr Umemoto!
The latest (as of this writing) GCC port to FreeBSD 9.0 ended up creating some compile problems when I did a
portupgrade -ra: /usr/ports/graphics/tiff couldn’t find some libraries:
g++46: error: /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/crtbeginS.o: No such file or directory g++46: error: /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/crtendS.o: No such file or directory *** Error code 1
The problem is that there is no more 4.6.3 directory once you install 4.6.4. I didn’t bother debugging the port problem, though I probably should have and informed the port maintainer and all of those good citizenship steps but instead took a shortcut that solved the problem:
cd /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/ ln -s 4.6.4 4.6.3 cd /usr/ports/graphics/tiff make clean portupgrade -ra
And all is good.
If you’re trying to install p5-XML-SAX-0.99 and get a
Can't locate XML/SAX/Exception.pm in @INC
error then you may need to
cd /usr/ports/textproc/p5-XML-SAX-Base make distclean make deinstall make install clean
Then you can
cd /usr/ports/textproc/p5-XML-SAX make distclean make install clean
And you should get an error free install. Apparently p5-XML-SAX-Base is a prereq that isn’t getting cleanly detected or updated in the make process for p5-XML-SAX.
I noticed the warning
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20090626/memcache.so' - /usr/local/lib/php/20090626/memcache.so: Undefined symbol "php_session_create_id" in Unknown on line 0
in my apache logs. Googling for it, some sites suggested that old
php.in files might the cause. But this is a pretty fresh install so I looked a little further and found a nerdstock note describing a similar problem. I checked my
/usr/local/etc/php/extensions.ini and finding that
extension=session.so came after
extension=memcache.so I moved it to the top of the file and the errors went away.
I am migrating my FreeNAS 7.x to a 8.x, which means copying the ZFS tank as there isn’t a tool for migrating the disks right now and upgrading them to the version of ZFS in 8.x. Kind of a pain in the butt that was made worse by the endless recurrence of an error like:
Received disconnect from xxx.xxx.xxx.xxx: 2: Packet corrupt
rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32)
rsync: connection unexpectedly closed (23734 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(601) [sender=3.0.7]
or something like:
Disconnecting: Packet corrupt
rsync: connection unexpectedly closed (581052724 bytes received so far) [receiver]
rsync error: error in rsync protocol data stream (code 12) at io.c(601) [receiver=3.0.8]
rsync: connection unexpectedly closed (202 bytes received so far) [generator]
rsync error: unexplained error (code 255) at io.c(601) [generator=3.0.8]
I figured my 7.x install had to be fine as I’ve been RSYNCing my server to it without error for about a year now, so the problem had to be in the new box and poking around for “packet corrupt rsync” on google was turning up a lot of *shrug* maybe bad RAM or a bad NIC. Hmmm… I tried command line push and pull from both boxes via SSH to see if I could get better results, no luck: a few files would transfer, maybe 10 seconds, maybe 5 minutes, then blop, bad packet, broken pipe, oh so informative “unexplained error” at io.c, start over. No way I was going to be able to transfer 3.5 TB 100MB at a time.
Finally I found this and checked the lovely graphical status monitor on the FreeNAS 7 box. It has 4GB of RAM, whichhas been plenty so far, but looking at the graph it was using about 95% of that memory. It had been up for 59 days so I was reluctant to reboot it, I mean uptime is a competition after all. But I took a dive and rebooted. Now, even with CIFS/SAMBA cranking some backup files simultaneously, RSYNC is running flawlessly at a nice steady 300mb/s, apparently limited by CPU (seems to be single threaded, maxing out one CPU and leaving the other idle, hmmm… problem for another day). I feel bad for doubting my FreeNAS 8 box, it was never the problem.
So if you’re getting RSYNC problems consider rebooting the server to free up RAM or even upgrading. The new box will have 12-16GB, which is about what is recommended for ZFS (1GB/TB) and things are looking pretty good. My RSYNC was running just -a –progress, no resource intensive -z option.
Odd choice for the default lat/lon in php.ini