Here’s a one off Ruby script to wrap up some ImageMagick labeling magic. This script takes all the JPG images in folder and applies the file’s name, as a label, to the bottom of the image. [gist id=2495001]

One of my development virtual machines went belly up after a recent system upgrade. After tinkering around at the grub> prompt to no avail, I booted a LiveCD, followed the instructions here: http://sazeit.com/articles/repair-or-reinstall-grub-with-boot-repair, and was up and running in minutes. Moral of the story; sometimes it’s more important to solve the problem than understand the underlying issues…not often, but sometimes :).

Dear spammers, You’ll be relieved to know that i am planning to get back to blogging more.  Thus you’ll have fresh tech posts where you can vainly attempt to post about Viagra and knockoff phones. PS, to human readers… I’ve been very busy with work and getting up to speed on web scraping, ruby, active record & SQLite3, Sinatra, and GIS. It’s an exciting time but a it mellows I’ll get back to blogging.

   Thursday, 2010-08-12. More adventures in Puppet: Fix this: err: /Stage[main]/Sudo/File[/etc/sudoers]: Could not evaluate: Could not retrieve information from source(s) puppet:///modules/sudo/files/etc/sudoers at /etc/puppet/modules/sudo/manifests/init.pp:11

By changing your file request (genuinely located at /etc/puppet/modules/sudo/files/etc/sudoers) from:

class sudo {
        package { sudo:
        ensure => present,
        }
        file { "/etc/sudoers":
                owner => "root",
                group => "root",
                mode => 0440,
                source => "puppet:///modules/sudo/files/etc/sudoers",
                require => Package["sudo"],
                }
}
To this:

``` bash
class sudo {
        package { sudo:
        ensure => present,
        }
        file { "/etc/sudoers":
                owner => "root",
                group => "root",
                mode => 0440,
                source => "puppet:///modules/sudo/etc/sudoers",
                require => Package["sudo"],
                }
}

This is using Puppet 2.6.2

Wow, this one stumped me for the better part of 12 hrs… So Puppet (the Ruby Gem) uses SSL certificates to authenticate to the Puppet Master.  I kept receiving the warning listed in the title of this post no matter how I altered my configs. Here’s the short version: Determine what Fully Qualified Domain Name is being used by the PuppetMaster to created the signing cert.  On my virtual platform this ended up being the hostname Add that hostname/FQDN and it’s IP address to your PuppetClient’s /etc/hosts like so: 173.999.999.999    hostname Now start up the PuppetMaster Server with the following command # puppetmasterd --verbose --no-daemonize Now invoke the puppet client like so: puppet agent --no-daemonize --verbose --server=HostnameOfServer Finally, now that we know it’s working well edit the /etc/puppet/puppet.conf on Puppet Client so that you have a server entry in the [main] section: [main] server=HostnameOfServer Tada!   Source of partial answer: Puppet hostname doesnt match server certificate - Server Fault.

When operating on a Windows operating system I miss using GNU/Linux’s Locate … so I replace it with a combination of Launchy and Search Everything. Search Everything indexes the names of all the files on your hard drive.  Launchy is a quick “Commandline Style” program launcher. After installing both programs, right click on the Search Everything Start Menu entry and modify the Properties.  Replace the target properties with “C:Program Files (x86)EverythingEverything.exe” -search " Now, right bring up the Launchy window and rebuild the catalog. Once Search Everything has a chance to index the contents of the hard drive, you can bring up Launchy type Search {Tab} STRINGTOSEARCHFOR. This will bring up the Search Everything window using your search term!

Noticed this today when checking my Google Analytics…. seems Civet blog is showing up from people searching for OpenEMR info. There’s a nice project available for anyone who would like to try out the OpenEMR system.  One of the project team members keeps an up to date virtual appliance ready to run in VMWare (or presumably imported and used in VirtualBox also). Nice way to try things out before implementing your own installation. Note: for security reasons it isn’t advisable to run the virtual appliance as a true deployment.  It’s easy to safely and securely deploy this via my previous blog post that describes the simple steps for installation in Debian/Ubuntu. Source link : http://www.bradymd.com/appliance/downloads.shtml

So, your instructions say to edit config.xml while setting up a program in Ubuntu/Debian Linux. You realize you don’t have a clue where it’s at… sudo apt-get install locate && sudo updatedb Then once it indexes your files, type a quick locate config.xml to find it. At this point you realize it’s buried in many sub folders of subfolders, but you need to edit it with your favorite editor (vim, nano, emacs..) If it’s the only result from the locate command, type vim locate config.xml``.  This uses command interpolation to substitute the answer of the locate request :). There should be a snappy way also to chop the results (if more than one appears)…but I’m out of time!

When editing multiple config files in complex installs it’s easy to lose track of where each parameter exists. Solution? Recursive grep with -n function ie grep -rn help\_me\_param . -n = line number and file name printed on left column of results -r = recursive -rn = win

phpinfo(). Trying to brute force servers is dumb… especially while leaving your phpinfo() online. Wouldn’t have gotten into these systems using those defaults but I still sleep safer at night with an active response IDS. /wave @ probably compromised box.