FreeBSD

On FreeBSD

Memcached doesn’t compile with -O3

Friday, June 20, 2014 

Most of the ports in FreeBSD compile just fine with -O3, and why not use it?  Not like compile time is a real constraint and one of the features of FreeBSD is that it is actually optimized for the hardware it runs on, rather than being generic, opaque code.

But memcached don’t play that game.  The easy thing to do is modify /etc/make.conf on error, then fix it back after recompiling, but that gets tedious.  The following edit to /etc/make.conf automates the process:

.if empty(.CURDIR:M/usr/ports/databases/memcached*)
CFLAGS= -O3 -pipe -march=native -mtune=native
.endif

.if (.CURDIR:M/usr/ports/databases/memcached*)
CFLAGS= -O2 -pipe -march=native -mtune=native
.endif

Posted at 13:23:41 UTC

Category: FreeBSD

Xabber now uses Orbot: OTR+Tor

Sunday, November 3, 2013 

As of Sept 30 2013, Xabber added Orbot support. This is a huge win for chat security. (Gibberbot has done this for a long time, but it isn’t as user-friendly or pretty as Xabber and it is hard to convince people to use it).

The combination of Xabber and Orbot solves the three most critical problems in chat privacy: obscuring what you say via message encryption, obscuring who you’re talking to via transport encryption, and obscuring what servers to subpoena for at least the last information by onion routing. OTR solves the first and Tor fixes the last two (SSL solves the middle one too, though Tor has a fairly secure SSL ciphersuite, who knows what that random SSL-enabled chat server uses – “none?”)

There’s a fly in the ointment of all this crypto: we’ve recently learned a few entirely predictable (and predicted) things about how communications are monitored:

1) All communications are captured and stored indefinitely. Nothing is ephemeral; neither a phone conversation nor an email, nor the web sites you visit. It is all stored and indexed should somebody sometime in the future decide that your actions are immoral or illegal or insidious or insufficiently respectful this record may be used to prove your guilt or otherwise tag you for punishment; who knows what clever future algorithms will be used in concert with big data and cloud services to identify and segregate the optimal scapegoat population for whatever political crises is thus most expediently deflected. Therefore, when you encrypt a conversation it has to be safe not just against current cryptanalytic attacks, but against those that might emerge before the sins of the present are sufficiently in the past to exceed the limitations of whatever entity is enforcing whatever rules. A lifetime is probably a safe bet. YMMV.

2) Those that specialize in snooping at the national scale have tools that aren’t available to the academic community and there are cryptanalytic attacks of unknown efficacy against some or all of the current cryptographic protocols. I heard someone who should know better poo poo the idea that the NSA might have better cryptographers than the commercial world because the commercial world pays better, as if the obsessive brilliance that defines a world-class cryptographer is motivated by remuneration. Not.

But you can still do better than nothing while understanding that a vulnerability to the NSA isn’t likely to be an issue for many, though if PRISM access is already being disseminated downstream to the DEA, it is only a matter of time before politically affiliated hate groups are trolling emails looking for evidence of moral turpitude with which to tar the unfaithful. Any complacency that might be engendered by not being a terrorist may be short lived. Enjoy it while it lasts.

And thus (assuming you have an Android device) you can download Xabber and Orbot. Xabber supports real OTR, not the fake-we-stole-your-acronym-for-our-marketing-good-luck-suing-us “OTR” that Google hugger-muggers and caromshotts you into believing your chats are ephemeral with (of course they and all their intelligence and commercial data mining partners store your chats, they just make it harder for your SO to read your flirty transgressions). Real OTR is a fairly strong, cryptographically secured protocol that transparently and securely negotiates a cryptographic key to secure each chat, which you never know and which is lost forever when the chat is over. There’s no open community way to recover your chat (that is, the NSA might be able to but we can’t). Sure, your chat partner can screen shot or copy-pasta the chat, but if you trust the person you’re chatting with and you aren’t a target of the NSA or DEA, your chat is probably secure.

But there’s still a flaw. You’re probably using Google. So anyone can just go to Google and ask them who you were chatting with, for how long, and about how many words you exchanged. The content is lost, but there’s a lot of meta-data there to play with.

So don’t use gchat if you care about that. It isn’t that hard to set up a chat server.

But maybe you’re a little concerned that your ISP not know who you’re chatting with. Given that your ISP (at the local or national level) might have a bluecoat device and could easily be man-in-the-middling every user on their network simultaneously, you might have reason to doubt Google’s SSL connection. While OTR still protects the content of your chat, an inexpensive bluecoat device renders the meta information visible to whoever along your coms path has bought one. This is where Tor comes in. While Google will still know (you’re still using Google even after they lied to you about PRISM and said, in court, that nobody using Gmail has any reasonable expectation of privacy?) your ISP (commercial or national) is going to have a very hard time figuring out that you’re even talking to Google, let alone with whom. Even the fact that you’re using chat is obscured.

So give Xabber a try. Check out Orbot, the effortless way to run it over Tor. And look into alternatives to cloud providers for everything you do.

Posted at 08:50:47 UTC

Category: FreeBSDself-publishingtechnology

Google outrage at ‘NSA hacking’

Friday, November 1, 2013 

Outrageous, OUTRAGEOUS I says!

Yeah yeah, the NSA didn’t pay you for the data this time?

Google outrage at ‘NSA hacking’

Posted at 01:18:25 UTC

Category: FreeBSDtechnology

cyrus-sasl-saslauthd-2.1.26 auth_krb5.c compile error

Saturday, January 5, 2013 

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!

Posted at 13:41:23 UTC

Category: FreeBSDtechnology

openldap-server-2.4.33_2

Thursday, January 3, 2013 

With FreeBSD 9.1 out, it is time get all my ports upgraded in advance of doing the OS update.  The process is fairly painless, but occasionally, especially if you are slacking in the updates, a change in configuration causes the usually completely automatic “portupgrade -ra” to fail.

One such update was “Upgrading 'openldap-sasl-server-2.4.31' to 'openldap-server-2.4.33_2” which failed with a

===>  openldap-server-2.4.33_2 conflicts with installed package(s):
      openldap-sasl-client-2.4.33_1

      They install files into the same place.
      You may want to stop build with Ctrl + C.
===>  License OPENLDAP accepted by the user
===>  Found saved configuration for openldap-server-2.4.33

===>  openldap-server-2.4.33_2 conflicts with installed package(s):
      openldap-sasl-client-2.4.33_1

      They will not build together.
      Please remove them first with pkg_delete(1).
*** Error code 1

Stop in /usr/ports/net/openldap24-server.

But because this is FreeBSD and the open source community actually provides support, unlike, say Microsoft, where such an error would languish for months, if not years, with out a patch or any advice on how to fix it, the port maintainer, Xin Li, answered my question in less than 20 minutes with the following advice:

cd /usr/ports/net/openldap24-server
make config

Check “SASL” is checked?

Following his directions, everything compiled perfectly.

Posted at 15:49:42 UTC

Category: FreeBSD

..Graphics/Tiff & GCC 4.6.4

Friday, June 29, 2012 

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.


  
Posted at 02:54:55 UTC

Category: FreeBSD

p5-XML-SAX-0.99 Install Error

Tuesday, May 8, 2012 

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.

Posted at 05:42:59 UTC

Category: FreeBSDtechnology

math/fftw3:

Sunday, September 25, 2011 

If you get a “Variable CFLAGS is recursive.” error when doing a portupgrade -ra on freeBSD, it appears the make file is broken. “break19” debugged it in this post.

at line 64 change #CFLAGS+= to #CFLAGS:=

his fix worked for me.

Posted at 23:58:57 UTC

Category: FreeBSDtechnology

PHP Startup: Unable to load memcache.so

Tuesday, September 13, 2011 

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.

Posted at 00:29:25 UTC

Category: FreeBSDtechnology

Rsync corrupted MAC on input

Saturday, August 27, 2011 

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.

Posted at 00:24:53 UTC

Category: FreeBSDtechnology