Coding

Managing services on Solaris 10 is nothing like Linux. There are no /etc/init.d/ scripts, no service command, no chkconfig. Instead, Solaris uses SMF — the Service Management Facility — and everything goes through svcadm. If you are new to Solaris, this can feel unnecessarily complicated. It is not, once you learn the pattern. Disabling a service You need root privileges or sudo access. The command is: svcadm disable network/cswpuppetd:default The argument is the service FMRI (Fault Management Resource Identifier). For Puppet installed from OpenCSW, the FMRI is network/cswpuppetd:default. The :default part refers to the default instance of the service. Some services have multiple instances, but most only have one. ...

Puppet on Solaris 10 stores its logs in the SMF log directory, which is different from the /var/log location you might be used to on Linux. If you are looking for the usual log files and cannot find them, this is probably why. Agent logs The Puppet agent (puppetd) runs as an SMF service, and its log is at: /var/svc/log/network-cswpuppetd:default.log To watch it in real time: tail -f /var/svc/log/network-cswpuppetd:default.log Master logs The Puppet master (puppetmasterd) follows the same pattern: ...

The build script from the last post turns your source code into something runnable. But it does not tell you which version of the source code you are building. That is where version control comes in. I am going to use Subversion for this post because that is what most of the projects I have worked on have used, and it is still the most common version control system in enterprise Java development. Git is fine for other kinds of projects, but the concepts here apply regardless of which system you choose. ...

I wrote my first build script in my second year of college. It was a shell script that compiled a few Java files and copied the output into a folder. It worked. For that project, at least. Three years later, working on a team project with five other developers, I realised that script was useless. It assumed a specific directory layout. It assumed a specific version of the JDK. It assumed nobody had moved the source files. It assumed the build machine had the same libraries installed as my laptop. It assumed a lot of things, and every assumption was a potential failure point. ...

Every project I have worked on, from small college assignments to larger team efforts, has eventually hit the same wall: someone runs the build, something breaks, and nobody knows why. The code was fine five minutes ago. The build server is down. The classpath is wrong. The compiled output is three versions behind. It is frustrating, it is wasteful, and it is entirely preventable. The fix is a build script. ...

Firefox 4 just dropped and you want to try it without losing your current setup? You can run both versions at the same time. Add the Mozilla Daily PPA, update, then install: sudo add-apt-repository ppa:ubuntu-mozilla-daily/ppa sudo apt-get update sudo apt-get install firefox-4.0 Firefox 3 stays as firefox. Firefox 4 runs as firefox-4.0. Both show up in your applications menu, or you can launch them from the terminal whichever you need.

Got this from Puppet? err: Could not retrieve catalogue: Could not find class php in namespaces standardbuild at /etc/puppet/manifests/templates.pp:15 on domain.internal.com The error points at a missing class, but the real culprit is often a missing closing brace somewhere above that line. Puppet’s parser gets confused and reports the wrong thing. Check your manifests for unmatched { and }. A syntax highlighter helps — or just count your braces.

Hit phpize and got a “not found” error? You’re missing the PHP development package. sh: phpize: not found ERROR: `phpize' failed On Ubuntu or Debian, grab it with: sudo apt-get install php5-dev That’s it. phpize should work after that.

Spotted this broken link on the Chrome Extension Labs page. Looks like the Google developers forgot to update the path. Archived link: https://web.archive.org/web/2014/http://code.google.com/chrome/extensions/apps.html

The idea that you could push code to production without anyone touching a server, running a script, or holding their breath still sounds a bit mad to most developers. Most teams deploy like this: someone merges code, someone else pulls it down on a staging server, runs the tests manually, fixes whatever broke, then schedules a deployment window. Someone SSHs into production, runs a script or types commands by hand, crosses their fingers, and hopes nothing catches fire. If something does go wrong, you roll back by remembering what the last working version was and praying your backups are current. ...