Spotify on 64bit FreeBSD 9.1

Perhaps a little over a year ago Spotify became my new choice for music.  My mp3 collection is stale and unorganized, and I'm not feeling like taking either the time or money to update and organize it.  I used Pandora for awhile, but their music selection as of a year ago was far smaller, and their desktop client refused to work for me on any OS / architecture combination I tried.

So, with my still fresh install of FreeBSD amd64, what was I to do to run the 32-bit only spotify client?  Setup a 32-bit environment of course.

I more or less followed what is written up here: http://forums.freebsd.org/showthread.php?p=191438

When running make distribution, it failed with an error that sendmail's freebsd.cf file didn't exist so couldn't be installed.  Looking around the intarwebs, I ran into a number of reports regarding a tinderbox bug that caused exactly this, but I was not using tinderbug.  Ultimately, I just ran 'make' by hand in /usr/src/etc/sendmail and "make distribution" worked happily.

Just setting the display in the chroot environment didn't work out for me.  Eventually I installed x11-servers/xephyr.  Then it was just a matter of running Xephyr -ac :1 in the host, setting the DISPLAY variable to localhost:1 in the chroot environment, and I was able to get Spotify up and running under wine.

Simple Opensmtpd Configuration

Having recently reverted my primary home desktop to FreeBSD, I went looking for a method to send out notifications and the like to my gmail account.  Typically I would install postfix, but that was such a case of overkill in this case that I wanted something simpler.  Before I moved to rolling my own, I went looking for a solution, and ran across opensmtpd.  Specifically, I found this guide: https://cooltrainer.org/2012/06/06/external-mailing-on-freebsd/

It turns out that there have been some updates in the past few months such that the configuration example given will not work.  Below is my working example of smtpd.conf (everything else in the post should be fine).

listen on 127.0.0.1

map "aliases" source db "/usr/local/etc/mail/aliases.db"
map "secrets" source db "/usr/local/etc/mail/secrets.db"

accept for local alias aliases deliver to mbox
accept from local for domain gmail.com relay via "tls+auth://smtp.gmail.com:587" auth "secrets"

Brackets in the map config line are optional, and will eventually be removed alltogether.

More importantly, the configuration options for a relay host are now all put into that URL format.

I'm not really a jerk

It turns out there were a few comments here, but I hadn't configured any notification method so I completely missed them.  Who doesn't enjoy being an unintentional jerk.

Embarassing

I just applied for a PAUSE ID so I could go about uploading Twitter::Shell::Lite and submitted my homepage link as 'absurddoctor.blogger.com'. With any luck, they don't actually attempt to look at that in the first place ;p

I have been a bash user for almost as long as I have been logging into unix systems. I stole the basis of my now standard bash setup from a predecessor at the current $job. It gave me a two-line nicely-colored prompt which included (most importantly)the time, pwd, and username@hostname. I tend to be logged into a number of hosts at once, sometimes more than once, so having all that info quickly visible helps me to avoid getting 'lost' and either wasting time figuring out where I am. It's been tweaked here and there over the last 5-6 years as I found things that annoyed me, or found something nifty someone else had done, but for the most part it has held up well.

Well looking around git-hub for fun this morning, I ran across oh-my-zsh. This looked like a nifty idea, so I did a bit of research trying to compare bash to zsh. From what I can see, most of what you can do in one you can do in the other, but configuring zsh is much simpler. The setup of oh-my-zsh seemed much niftier than my current bash setup (the tab completion alone makes it awesome), so I decided to convert all of my working environments. I forked off so I could keep my personal updates easily available everywhere, and now have zsh setup as my default shell in every environment I spend much time in. I do wonder if I made a mistake in adding my changes directly to my fork of .oh-my-sh ... that is going to make it impossible to push anything which might have wider appeal back up. I'll probably go ahead and create a new repo to include all of my envirnoment related shite, then redo the fork so I can actually be useful. Someday, anyway.

My bash config ended up being slightly different everywhere. While I setup a git repo box at work and had everything in repos there, I still never managed to really keep things up to date. The same problem occurred on an even worse scale for my vim configs ... so I finally have a core for that up on github and have updated to that everywhere.

Contributing Is Fun

While cleaning up my amazon wish list a bit I noticed that I had a number of things that were 5+ plus years old. I deleted what I no longer thought would be useful, and decided I would begin buying one thing off my wish list each month (as long as it wasn't too expensive). After deletions, the oldest item on my wish-list was Mastering Algorithms with Perl. Used, the price was something like $3.28, and then $3.99 for shipping. Granted, the book is ten years old, so I expect the code to be crufty ad old-fashioned. I'm hoping I can still manage to learn a few things though, especially if I try to work out implementations in 'modern perl' ... or if I feel really, ambitious, perl 6.

Converting from syslog-ng to rsyslog

A few years ago I ended up tasked with creating an in-depth monitoring solution for use by our clients. I was still doing my research on the topic when I was informed that not only had a client ordered this not-yet-created monitoring system (which I hadn't been informed of), but they had gone live with informing anyone at all, and were now upset that the monitoring system wasn't in place. So I now had a day to settle on the plan for a system and to implement it.

Luckily for me, I found out there were really only a few specific items this particular client was expecting to be monitored, so I decided to go with a central log server based system. A small program installed on each of their servers would run via cron, and inject warnings and notification into the outgoing syslog stream. As I had begun leaning towards a syslog based system, I had spent much of my time researching what to use to handle both the storage of a potentially large amount of logs, and the analysis required to make the whole thing useful. At the time, the only viable non-commercial offering seemed to be syslog-ng. It could supposedly handle a very large load, it could be used to handle a lot of the initial filtering, and could either pipe out to other programs for analysis, or easily write to many places for slightly delayed analysis. Ultimately, I configured it to store everything in one area of the disk, and to look for potentially interesting items and store those in another area, where a script running from cron would consume anything that came in, sending out email alerts and trouble tickets as required. It also use rrdtool to track and graph various stats like cpu usage, diskspace, and etc (this was because I was modifying code already being used for internally that happened to do this on a small scale for our own equipment).

The system has been hacked on over the past few years, and went through one hardware update. Now we are giving it a rather significant hardware upgrade, and want to make it more user friendly. Part of this user friendliness is to provide a web interface for viewing logs and interesting stats, and to allow configuration of monitors and etc by the user (right now configuration changes have to be requested and implemented by one us). While designing the new system, we decided to go with the possibility of logging at least some things to an sql database (everything would be nice, but I'm not convinced we have enough server power in place for that). The base system will be FreeBSD 7.2, and i spent most of a day trying to install syslog 3.0.4 with the ability to log to sql natively compiled. I tried using both the port (which was actually 3.0.3), and grabbing the source, but could never get it to compile with sql support enabled. It would appear to find the libnet libraries at first, but ultimately decided it really couldnt see them and would fail to compile. I'm far from being an expert on unix build tools, but usually if I fumble around long enough I find the correct invocations to get where I want to be. I enlisted a coworker who mentioned needing something to do, but he had no better luck.

syslog-ng does have the ability to dispatch logs to a fifo pipe, so I could do that and write or copy a script to handle the actual writing to the database ... but since I am already worried about performance I decided to look elsewhere again.

rsyslog was still very new when I first setup this system, so it wasn't much of a contender. However, it has really grown, so I'm going to give it a test run. After making sure the port system had a version I was happy with, i ran 'make install', and a few minutes later I had syslog server logging to mysql. I have another co-worker dealing with the web interface portion (I'll probably just have him hack up phpLogCon), I expect I'll need a day or so to rewrite and test the log analysis code I have in place now, and then I can begin slowly moving our servers to the new system. Hopefully by the end of next week all will have gone well, I'll be able to move our clients over, and move on to the next project.