1. You have successfully installed chef-client.
2. You have a working knife config.
3. You have either a working open source chef server or you’re using enterprise chef.
Note: Enterprise Chef comes with 5 free nodes!
So let’s start off by installing my amazon_s3cmd cookbook like so:
1
| |
Next you’ll need a secret key for your databag.
1
| |
Now create a new data bag item that will be used.
1 2 3 | |
If you get the following error below…
1
| |
..make sure you export your editor as EDITOR
1
| |
Verify your encrypted data bag items.
1 2 3 4 5 6 7 8 9 10 11 12 13 | |
Now check your decrypted data bag items
1 2 3 4 | |
Copy your secret key to your node.
1 2 3 | |
Move your key to /etc/chef.
1
| |
Include the amazon_s3cmd::source recipe in your node’s run_list if you want the latest beta version which supports adavnced features:
1 2 3 4 5 6 | |
Run chef-client on your node to update it’s configuration and install & configure s3cmd like so:
1
| |
If you took the defaults, your s3cmd’s config file will be located at /root/.s3cfg and should look something like the following:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 | |
If you made it this far; CONGRATS! You should now be ready to back files up to S3.
So, for example, let’s say you have some backups in /mnt/backups you’d like to tar up and copy to S3.
1 2 | |
You can tar up your backups like so:
1 2 3 4 5 6 7 | |
As you can see above, this will create a tar archive of the /mnt/backups directory and save it as /tmp/backups.tar.gz.
Next, let’s create an S3 bucket that we can use to copy our backups to like so:
1
| |
Now, copy your backup to your S3 bucket:
1
| |
Finally, you should now be able to display the contents of your bucket like so:
1
| |
You’d like to contribute? That’s freaking awesome! Here’s how.
]]>Awright, let’s get crackin’ and hopefully learn some stuff! :).
First, tail -f whatever log you’re writing kernel messages to. For most people this is either /var/log/messages or /var/log/kern.log.
1
| |
Second insert your SDCARD in whatever device you’re using to do the formatting with.
You should now see similar output in your terminal running tail -f like below:
1 2 3 4 | |
As you can see from above device mmcblk0 is the device name of my SDCARD. This will probably be different for you.
Let’s use fdisk -l to make sure we’ve identified the right device.
1 2 3 4 5 6 7 8 9 10 11 | |
Since I know my SDCARD is 64GB in size I’m pretty confident I’ve got the right device.
Now let’s wget our Raspbian image like so:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | |
Next use unzip to unzip the Raspbian disk image like so:
1 2 3 | |
Now use ddto write the Raspbian disk image to your SDCARD like so:
1 2 3 4 5 6 | |
If you made it this far congrats! You should be ready to insert you SDCARD into your pi, hook things up, plugin the power adapter, and boot up Raspbian.
However, I had an issue in which I simply had no video what so ever. If you experience the same, and you’re using HDMI, you may need to do the following to get video working on your pi. This assumes you have your SDCARD mounted at /media.
1 2 3 | |
Uncomment the above line in config.txt to enable hdmi_safe mode.
Well that’s it. Hopefully at this point you can at least boot up your pi running Raspbian!
Stay tuned to my blog for future posts on the Raspberry Pi!
]]>First download and install my bind-chroot cookbook from within your main chef-repo like so:
1
| |
Include the bind-chroot::chroot recipe in your node’s runlist like so:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | |
Update your node’s definition like so:
1 2 3 | |
Now run chef-client on the node you want to deploy bind9 to like so:
1 2 3 | |
If all went well named should now be installed in a CHROOT, jailed to /var/bind9/chroot, & listening. We can check if named is listening with netstat like so:
1 2 3 4 5 6 7 8 9 | |
As you can see from the netstat output above, named is listening on TCP and UDP ports 53.
By default Bind9, on Debian & derivatives, is already configured as a “caching only” name server.
Let’s test Bind9’s caching by looking up a domain, say google.com, with our dns client dig like so
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 | |
Note the line containing “Query time” shows our query took 26 milliseconds to complete. Now the domain google.com should be cached so let’s do another query and see if our time improves.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 | |
As you can see above our query took 0 milliseconds! That’s obviously an improvement from our original query time of 26 milliseconds.
This record will be cached according to the TTL (Time To Live) of the zone record.
Let’s do another query and suppress some of dig’s output like so:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | |
The number 300 from the above dig output is the time remaining until the DNS cache will be updated in seconds. Since this is our caching nameserver if we wait a few seconds/minutes and do another query this number should decrease like in the output below:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | |
Notice time remaining until cache will be updated on our caching bind9 name server has now decreased from 300 seconds to 47 seconds. So if we wait more then 47 seconds and do another query we should see a number much greater then 47.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | |
As you can see time until cache will be updated is back up to 300 seconds or 5 minutes.
If we want to find the actuall TTL for google.com we’ll need to query an authorative name server for google.com. Let’s get a list of authorative name servers with the following dig command like so:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | |
So from the above output we see that name server ns1.google.com is authorative for google.com.
If we query ns1.google.com we can get the actual TTL like so:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 | |
Notice the TTL is 300. Also notice the line containing “aa” following the line containing “HEADER” as shown below:
1
| |
Notice the “aa”. This means this is an authorative answer for the domain google.com.
If we do another query you’ll see the TTL remains 300 and doesn’t change like it did against our own local bind9 server. This is the actual TTL (Time To Live) for domain google.com since we queried an authorative name server.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 | |
We can now dump our DNS cache to file with the command below. If you’re using my bind-chroot cookbook your cache file should be located at /var/bind9/chroot/var/cache/bind/named_dump.db.
1
| |
We can now view the contents of our cache and look for google.com like so:
1 2 3 4 5 6 7 8 9 10 | |
You can see, by default, bind9 cached google.com for ~172385 seconds or ~47 hours!
]]>We’ll start by cleaning a few things up.
1
| |
1
| |
Now let’s search for packages that have been installed only partially and fix them.
1
| |
Now make sure no packages are on hold like so:
1
| |
If you receive no output from the two dpkg commands above it should be safe to start the upgrade.
Update your source list located at /etc/apt/sources.list. If you’re not on squeeze then substitute ‘squeeze’ with the version you’re on.
1
| |
Your source list at /etc/apt/sources.list should now look something like the following:
1 2 3 4 5 6 7 8 9 10 11 | |
Note: Your URLs will likely differ from mine; especially if you don’t live in the US.
Now let’s resynchronize your package index files from the new sources that point to Wheezy.
1
| |
Next install the newest versions of all packages currently installed on the system according to /etc/apt/sources.list.
Note: This is pretty much the point of no return!
1
| |
Now actually upgrade your current Debian distribution. Apt-get dist-upgrade will perform the same as upgrade and intelligently handle changing dependencies with new versions of packages.
1
| |
Now reboot.
1
| |
After logging back into your Debian box let’s check for package issues like we did before.
1 2 | |
You may need to do the upgrade dist-upgrade song-and-dance one final time.
1 2 | |
Finally check what Debian version you’re currently on.
1 2 3 | |
If the output of the above command is 7.0 you are now running Debian Wheezy!
Now go have a beer or three!
]]>The basic design is to have your user(s) run the following BASH shell script, which will then call a Perl script that builds a postscript file, then the BASH script will send the postscript file to the printer.
Here is the shell script your user(s) will run.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 | |
The BASH script basically asks the user what printer they want to print to, set’s the user’s DEFAULT printer, then calls your Perl script using the module PostScript::MailLabels to build a postscript file, then the BASH script sends it to the user’s printer.
Here is the Perl script which does most of the heavy lifting.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 | |
The Perl script basically asks the user what’s the name of the file they want to print, reads in the file (; delimited in this case), & outputs a postscript file.
Obviously you will have to make some changes in order to get these scripts to work in YOUR environment!
Note: This is for Avery labels with Avery code 5961. Please review PostScript::MailLabels’s documentation on CPAN to see if the module supports your particular labels or not. You will also probably have to tweak the “labelsetup” and “definelabel” parts to fit your needs. Also note that the file this script reads is in the format of name;strete1;street2;city;st;zip$ semicolon delimited with a trailing $. You will have to tweak the regex if your file is in a differet format.
Disclaimer: This blog entry comes with NO expressed warranty, guarantee, support, or maintenance of any kind! Use at your own risk!
Good luck and happy printing!
]]>I won’t copy what’s in Cisco’s guide but I’ll add the following:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 | |
Here is the Perl script that can securely execute commands on as well as securely copy files from a server.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 | |
perl -MCPAN -e 'install Net::Hulu'
Net::Hulu provides methods to download all XML-formatted RSS feeds provided by hulu.com and return a data structure to the user containing the Data from the RSS feeds.
The following methods will download RSS feeds from hulu.com to directory where Hulu.pm is installed.
Method download_recent_videos_xml will download RSS feed for recent videos.
Method download_recent_shows_xml will download RSS feed for recent shows.
Method download_recent_movies_xml will download RSS feed for recent movies.
Method download_highest_rated_videos_xml will download RSS feed for highest rated videos.
Method download_popular_videos_today_xml will download RSS feed for today’s popular videos.
Method download_popular_videos_this_week_xml will download RSS feed for this week’s popular videos.
Method download_popular_videos_all_time_xml will download RSS feed for most popular videos of all time.
Method download_soon_to_expire_videos_xml will download RSS feed for soon to expire videos.
Method download_recent_blog_postings_xml will download RSS feed for recent blog postings to hulu.com.
The following methods will process all RSS feeds provided by hulu.com.
Method get_recent_videos returns a list of recently added videos to the user.
Method get_recent_shows returns a list of recently added shows to the user.
Method get_recent_movies returns a list of recently added movies to the user.
Method get_highest_rated_videos returns a list of highest rated videos to the user.
Method get_popular_videos_today returns a list of most popular videos today to the user.
Method get_popular_videos_this_week returns a list of most popular videos this week to the user.
Nethod get_popular_videos_all_time returns a list of most popular videos of all time to the user.
Method get_soon_to_expire_videos returns a list of soon to expire videos to the user.
Method get_recent_blog_postings returns recent blog postings for hulu.com to the user.
For detailed information on the Perl Module Net::Hulu, please visit the project’s home page on CPAN at http://search.cpan.org/~jlophty/Net-Hulu-0.02/lib/Net/Hulu.pm.
h2xs -b 5.6.0 -XA -n Net::Hulu
This will remove all autoload and XS portions of the module, adding backwards compatibility with Perl versions >= 5.6.0, and making it a ‘Pure Perl’ implementation.
Disclaimer: This blog entry comes with NO expressed warranty, guarantee, support, or maintenance of any kind. Use at your own risk!
]]>