Skip to content

Instantly share code, notes, and snippets.

@hesco
hesco / gist:4468021
Created January 6, 2013 15:46
With proper permissions, my code is unable to chdir; why?
This one has me stumped.
The user with which I am developing this owns that directory,
and in a bash shell, has no issues whatsoever changing to that
directory. Yet somehow (driven from my test script), my module
seems unwilling to make this change. And as a consequence, my
script is blowing up several lines later (thankfully) when it
attempts to overwrite the site I want to update with the updated
code.
@hesco
hesco / gist:4571823
Created January 19, 2013 10:24
Curious to know what may be illegal about this syntax . . .
perl t/103-sometest.t
ok 1 - use MyApp::SomeModule;
param(): illegal syntax at lib/MyApp/Base.pm line 58
# Tests were run but no plan was declared and done_testing() was not seen.
------------------------------
package MyApp::Base;
#!/usr/bin/env perl
use strict;
use warnings;
use Test::More;
use Test::Mojo;
use Data::Dumper;
use FindBin;
require "$FindBin::Bin/../scripts/www/admin/password_reset";
my $t = Test::Mojo->new();
@hesco
hesco / gist:5020130
Last active December 14, 2015 03:19
Brand new to both Mojolicious and to HTML::FormHandler, only been toying with these tools for less than an hour a day over the past week or so, plus perhaps a day of reading perldoc and tutorials and watching videos. Here is what I've got and what I'm seeing. My question is this: What happened to my \@config_files on the way to instantiating my …
logs . . .
[Sun Feb 24 12:18:33 2013] [debug] GET /password_reset (Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.19 (KHTML, like Gecko) Chrome/25.0.1323.1 Safari/537.19).
[Sun Feb 24 12:18:33 2013] [debug] Routing to a callback.
The password_reset scripts says: $VAR1 = {
'config_files' => [
't/conf/myapp_api.ini'
]
};
::ResetPassword->my_app says config_files is: $VAR1 = [
$ perl 9998-throw-me-away.t
::ResetPassword->myapp says config_files is: $VAR1 = [
't/conf/myapp_api.ini'
];
ok 1 - The object isa MyApp::ThisApplication
1..1
-------------------------------------
@hesco
hesco / gist:5177119
Created March 16, 2013 16:19
I am writing a module (App::DB::Backup, which uses Moose) which `extends 'App::Base', 'App::DB';` App::DB also `extends 'App::Base';` (which both also use Moose). One of the new module's attributes has a default which wants to use a ->cfg attribute provided by the ::Base class. But trying to instantiate my new class gives me a 'Attribute (cfg) d…
-----------------------------
the errors I am seeing
-----------------------------
$ perl t/9999-app-db-backup.t
# Testing App::DB::Backup
ok 1 - use App::DB::Backup;
Attribute (cfg) does not pass the type constraint because: Validation failed for 'Config::Simple' with value undef (not isa Config::Simple) at /usr/local/lib/perl/5.10.1/Moose/Meta/Attribute.pm line 1274
Moose::Meta::Attribute::verify_against_type_constraint('Moose::Meta::Attribute=HASH(0x9c3dd98)', undef, 'instance', 'App::DB::Backup=HASH(0x9ce6f10)') called at /usr/local/lib/perl/5.10.1/Moose/Meta/Attribute.pm line 1261
Moose::Meta::Attribute::_coerce_and_verify('Moose::Meta::Attribute=HASH(0x9c3dd98)', undef, 'App::DB::Backup=HASH(0x9ce6f10)') called at /usr/local/lib/perl/5.10.1/Moose/Meta/Attribute.pm line 531
@hesco
hesco / gist:5448605
Last active December 16, 2015 14:28
vagrant provision errors
$ vagrant provision
[default] Running provisioner: puppet...
Running Puppet with init.pp...
stdin: is not a tty
Could not find class stunnel4 at /tmp/vagrant-puppet/manifests/init.pp:26 on node vagrant-debian-squeeze.vagrantup.com
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!
cd /tmp/vagrant-puppet/manifests && puppet apply --modulepath '/etc/puppet/modules:/tmp/vagrant-puppet/modules-0' init.pp --detailed-exitcodes || [ $? -eq 2 ]
@hesco
hesco / gist:5471100
Last active December 16, 2015 17:30
errors running: vagrant plugin install vagrant-rackspace
But why? how do I add the files found below by locate to my path?
-- Hugh
07:23:26 {(ccfe790...)} ~/sandbox/samora/samora002$ vagrant plugin install vagrant-rackspace
Installing the 'vagrant-rackspace' plugin. This can take a few minutes...
/opt/vagrant/embedded/lib/ruby/1.9.1/rubygems/installer.rb:562:in `rescue in block in build_extensions': ERROR: Failed to build gem native extension. (Gem::Installer::ExtensionBuildError)
/opt/vagrant/embedded/bin/ruby extconf.rb
@hesco
hesco / gist:5474233
Created April 27, 2013 19:10
mpapis: /opt/vagrant/embedded/bin/ruby -rrbconfig -e 'puts RbConfig::CONFIG.sort.map{|k,v| "#{k}: #{v}" }'
03:07:46 {master} ~/sandbox/samora/samora002$ /opt/vagrant/embedded/bin/ruby -rrbconfig -e 'puts RbConfig::CONFIG.sort.map{|k,v| "#{k}: #{v}" }'
ALLOCA:
AR: ar
ARCHFILE:
ARCH_FLAG:
AS: as
ASFLAGS:
BASERUBY: ruby
BUILTIN_TRANSSRCS: newline.c
CAPITARGET: nodoc
@hesco
hesco / gist:5477562
Created April 28, 2013 17:18
Unexpected name resolution issue when submitting a CSR to puppetmaster
I've been building a nova script to launch a RackSPaceCloud instance,
which is intended to grab its configuration from puppet.
This step has been working without a hitch until now.
(I have sanitized the real domain and host names to protect a client's privacy).
The real puppet.example.com is in DNS and running host on that domain returns expected results.
the client's hostname is defined in the /etc/hosts file.
I'm confused where this name resolution issue is coming from.
Any guidance would be appreciated.