Remotely Reboot Windows with a VBS script

'==========================================================================
'
' COMMENT: Remotely reboots a PC.  May use machine name or IP address.
'
'==========================================================================

On Error Resume Next
mname = InputBox("Enter Machine Name", "Reboot Machine")
If Len(mname) = 0 Then Wscript.Quit

if Msgbox("Are you sure you want to reboot machine " & mname, vbYesNo, "Reboot Machine") = vbYes then

Set OpSysSet = GetObject("winmgmts:{impersonationLevel=impersonate,(RemoteShutdown)}//" & mname).ExecQuery("select * from Win32_OperatingSystem where Primary=true")
for each OpSys in OpSysSet
OpSys.Reboot()
next
end if

Video: Adding Pictures to Gallery3

A quick How-To video I made on how to add pictures to a Gallery3 photo gallery.

Display EXIF Data on WordPress Gallery Post Image

In this post I will talk about how to display EXIF data for an image in a WordPress post or native gallery.

In order to do this you need to modify your sites theme.

First start by addign the below function to your themes function.php file.

/*********************************************************************************
  Using WordPress functions to retrieve the extracted EXIF
  information from database
*/
function mdr_exif() { ?>
  <div id="exif">
    <h3 class='comment-title exif-title'><?php _e('Images EXIF Data'); ?></h3>
    <div id="exif-data">
      <?php
      $imgmeta = wp_get_attachment_metadata( $id );
      // Convert the shutter speed retrieve from database to fraction
      $image_shutter_speed = $imgmeta['image_meta']['shutter_speed'];
      if ($image_shutter_speed > 0) {
        if ((1 / $image_shutter_speed) > 1) {
          if ((number_format((1 / $image_shutter_speed), 1)) == 1.3
            or number_format((1 / $image_shutter_speed), 1) == 1.5
            or number_format((1 / $image_shutter_speed), 1) == 1.6
            or number_format((1 / $image_shutter_speed), 1) == 2.5){
            $pshutter = "1/" . number_format((1 / $image_shutter_speed), 1, '.', '') ." ".__('second');
          } else {
            $pshutter = "1/" . number_format((1 / $image_shutter_speed), 0, '.', '') ." ".__('second');
          }
        } else {
          $pshutter = $image_shutter_speed ." ".__('seconds');
        }
      }

      // Start to display EXIF and IPTC data of digital photograph
      echo "<p>" . date("d-M-Y H:i:s", $imgmeta['image_meta']['created_timestamp'])."</p>";
      echo "<p>" . $imgmeta['image_meta']['camera']."</p>";
      echo "<p>" . $imgmeta['image_meta']['focal_length']."mm</p>";
      echo "<p>f/" . $imgmeta['image_meta']['aperture']."</p>";
      echo "<p>" . $imgmeta['image_meta']['iso']."</p>";
      echo "<p>" . $pshutter . "</p>"
      ?>
    </div>
    <div id="exif-lable">
      <?php // EXIF Titles
      echo "<p><span>".__('Date Taken:')."</span>";
      echo "<p><span>".__('Camera:')."</span>";
      echo "<p><span>".__('Focal Length:')."</span>";
      echo "<p><span>".__('Aperture:')."</span>";
      echo "<p><span>".__('ISO:')."</span>";
      echo "<p><span>".__('Shutter Speed:')."</span>"; ?>
    </div>
  </div>
<?php }

Then add the following to your style.css

/*EXIF table*/
#exif { overflow: hidden; margin: 0; padding: 0 10px 0 0; }
#exif-lable { margin: 0 0 0 15px; width: 125px; }
#exif-lable p { margin: 0; }
#exif-lable span { font-weight:bold; }
#exif-data { overflow: hidden; margin: 0; float: right; width: 540px; }
#exif-data p { margin: 0 10px; }

And lastly you need to add the function you created above to your image.php file. This may be the most difficult part. Depending on your theme, you need to find a space for the EXIF table to live on the image page. You will also need to play with the style.css entry you added to make it look correctly on your site.

<?php mdr_exif(); ?>

Git Commit eMail Notifications

Git’s Native eMail Notifier

From the repository you wish to send email on commits.

cd .git/hooks
mv post-receive post-receive.bkp
ln -s /usr/share/git-core/contrib/hooks/post-receive-email post-receive
git config hooks.mailinglist "mailinglist@example.com"
git config hooks.emailprefix "[SUBJECT PREFIX] "  # note the trailing space

Git Commit Notifier

This ‘plugin’ will allow you to send an email every time a commit is committed to the repository. You may use this on the central repository to keep everyone following the project up to date.

To use this plugin, you first need to compile the script, then add the config information to each repository you wish to use it on.

To Install Git Commit Notifier

On Fedora 12 you first need to install Ruby and a few other dependences. After you download the needed dependences, you may compile the script.

yum install ruby rubygems hpricot rubygem-hpricott
gem install git-commit-notifier

To Configure Git Commit Notifier

In your repository’s .git/hooks folder or if it’s a “bare” repository, just the hooks folder. Create a file named post-receive with the following content.

#!/bin/sh
git-commit-notifier ../git-commit-notifier.yml

Once you have saved the file, you need to make it executable.

chmod 775 post-receive

After you have made the hook executable, check up one directory to the repository’s .git directory. From here you need to create and modify your git-commit-notifier’s config file. Start out by creating a file named git-commit-notifier.yml, and copy the below config to it.

Git Commit Notifier Config File

# The recipient for the commit:
mailinglist: developers@example.com

# set to true if you want to ignore empty merge messages
ignore_merge: false

# Optional parameter for the subject-line of the mail
# emailprefix: GIT

# Decorate files with link to a webview. Possible values: none or gitweb
link_files: none

# select the delivery method: smtp or sendmail
delivery_method: sendmail

# settings for the smtp server
smtp_server:
address: localhost
port: 25
domain: localhost
user_name: user@localhost
password: password
authentication: plain
enable_tls: false

# settings for sendmail
sendmail_options:
location: /usr/sbin/sendmail
arguments: -i -t

# If link_files is set to "gitweb", you need to configure the path to your gitweb
# instance and the project name.
gitweb:
path: http://developerserver/path_to_gitweb
project: test.git

Installing the git, cgit web interface on a Fedora 12 server

cgit is fast web interface for the git. cgit has built a cache and is compiled in c so it’s very quick.

To start out, download the current version of cgit via git

git clone git://hjemli.net/pub/git/cgit

Next you need to setup the git submodule

cd cgit
git submodule init
git submodule update

Once your done, run get-git

make get-git

Then compile the software

make

And install it

make install

After you have installed cgit, you will need to setup Apache to run cgit. This is pretty easy, just edit your /etc/httpd/conf/httpd.conf file and add the following for the site you wish to run cgit on.

<Directory "/var/www/code.mattrude.com/">
      AllowOverride None
      Options ExecCGI
      Order allow,deny
      Allow from all
</Directory>

Once your done setting up cgit in Apache, you may configure cgit by creating a cgitrc file at /etc/cgitrc. Below is the example config file.

EXAMPLE CGITRC FILE
-------------------

# Enable caching of up to 1000 output entriess
cache-size=1000

# Specify some default clone prefixes
clone-prefix=git://foobar.com ssh://foobar.com/pub/git http://foobar.com/git

# Specify the css url
css=/css/cgit.css

# Show extra links for each repository on the index page
enable-index-links=1

# Show number of affected files per commit on the log pages
enable-log-filecount=1

# Show number of added/removed lines per commit on the log pages
enable-log-linecount=1

# Add a cgit favicon
favicon=/favicon.ico

# Use a custom logo
logo=/img/mylogo.png

# Enable statistics per week, month and quarter
max-stats=quarter

# Set the title and heading of the repository index page
root-title=foobar.com git repositories

# Set a subheading for the repository index page
root-desc=tracking the foobar development

# Include some more info about foobar.com on the index page
root-readme=/var/www/htdocs/about.html

# Allow download of tar.gz, tar.bz2 and zip-files
snapshots=tar.gz tar.bz2 zip

##
## List of common mimetypes
##

mimetype.git=image/git
mimetype.html=text/html
mimetype.jpg=image/jpeg
mimetype.jpeg=image/jpeg
mimetype.pdf=application/pdf
mimetype.png=image/png
mimetype.svg=image/svg+xml

##
## List of repositories.
## PS: Any repositories listed when section is unset will not be
##     displayed under a section heading
## PPS: This list could be kept in a different file (e.g. '/etc/cgitrepos')
##      and included like this:
##        include=/etc/cgitrepos
##

repo.url=foo
repo.path=/pub/git/foo.git
repo.desc=the master foo repository
repo.owner=fooman@foobar.com
repo.readme=info/web/about.html

repo.url=bar
repo.path=/pub/git/bar.git
repo.desc=the bars for your foo
repo.owner=barman@foobar.com
repo.readme=info/web/about.html

# The next repositories will be displayed under the 'extras' heading
section=extras

repo.url=baz
repo.path=/pub/git/baz.git
repo.desc=a set of extensions for bar users

repo.url=wiz
repo.path=/pub/git/wiz.git
repo.desc=the wizard of foo

# Add some mirrored repositories
section=mirrors

repo.url=git
repo.path=/pub/git/git.git
repo.desc=the dscm

repo.url=linux
repo.path=/pub/git/linux.git
repo.desc=the kernel

# Disable adhoc downloads of this repo
repo.snapshots=0

# Disable line-counts for this repo
repo.enable-log-linecount=0

# Restrict the max statistics period for this repo
repo.max-stats=month

Installing the GIT Daemon for Read Only Access to Repoistory

The idea here is to allow anyone to download your GIT repository using the native git protocol.  This is similar to the post I wrote about Creating a secure Git repository server, but the below method allows full read only public access to the repositories.

Start out by modifying the new file git-daemon.

vim /etc/xinetd.d/git-daemon

Add the below text to the file.

# description: The git daemon offers anonymous access to git repositories
service git
{
    disable        = no
    type           = UNLISTED
    port           = 9418
    socket_type    = stream
    wait           = no
    user           = git
    server         = /usr/libexec/git-core/git-daemon
    server_args    = --inetd --export-all --base-path=/var/git
    log_on_failure += USERID
}

You may need to change the location of the git-daemon (the above example is from Fedora) and you will need to update the location of your git repository directory.

The above configuration will share ALL the git repositories in the /var/git directory.

If you do not wish for the all repositories to be public, you may remove the --export-all flag and add a empty file named git-daemon-export-ok to the git repository you wish to still share.

Git Cheat Sheet

Git Global Setup

 git config --global user.name "Your Name Here"
 git config --global user.email you@example.com

Git Commands

Common Git Commands

To download a new git repository

(Public access)

git clone http://git.example.com/folder/project.git

Update an exciting repository

(From within the projects folder)

git pull

Comment a change

git comment file.txt

To Revert a comment

git revert ce963c9db00c25b3c1e6add1fe6032aef61a5bed

Commit

Modify the last commit

git commit --amend

Patches

Creating a patch

git diff file_with_changes > 0001-name_of_patch_file.patch
gzip 0001-name_of_patch_file.patch

Patching a file or directory

gzip -dc 0001-name_of_patch_file.patch.gz |patch -p1

Branching

Creating a new branch

git branch <branch>

or to create a branch and switch to it

git checkout -b <branch>

Pulling changes from branches

git checkout <branch_committing_to>

Now that your in the branch you want to add the changes to, run:

git pull . <branch_committing_from>

Changing to a different branch

git checkout <branch>

Deleting a branch

git branch -d <branch>

Deleting a remote branch

git push origin :<branch>

Pushing a branch to github

git push <remote_repository_name> <branch_name>

So that would be…

git push origin <branch>

Display branches on github

git remote show origin

Pulling a branch from github

git checkout --track -b <name_of_local_branch> origin/<name_of_remote_branch>

Tagging

Tagging a branch

git tag -a -m "tagging version 1.0" 1.0

Pushing the tag to github

git push --tags

Deleting a tag

git tag -d 1.0

Removing a deleted tag from github

git push origin :refs/tags/1.0

Submodules

To update existing submodules

git pull
git submodule init
git submodule update

To add a new submodule to a project

git submodule add <remote-host>:<project.git> <project.git>

So if you are adding project “program” from the example git server you will run

git submodule add git://example.com/program.git program

Creating an secure Git remote server

On the Server create the git repository

mkdir name-of-git-repo.git
cd name-of-git-repo.git
git init --bare

On the Client System create the git repo to import into the server

git init
touch README
git add README
git commit -m 'first commit'
git remote add origin git@REMOTE_SERVER:name-of-git-repo.git
git push origin master

Importing an SVN repo into git

To import a svn repo create a new git repo and run

git svn clone https://svn.foo.com/svn/proj
git commit

Git Links

Run a Secure git Repository on FreeNAS

Running a secure git repository on FreeNAS is pretty straight forward, once you understand what your trying to do.  If you have looked over my previous post “Creating a secure Git repository server” you understand that all you really need to do is connect to the git repository via ssh/ssl and copy back what you need.  The hardest part of using FreeNAS is creating the keys.

To start out, you need to create a user account on the FreeNAS system.  This will be a generic account that everyone who has write access will use.  You may also create a account for each person, and grant each of them access to the central repository.

After you have your account, follow my post on “Enable SSH Key Authorization on FreeNAS” to copy over the SSL key and setup the account.  Once you are able to log in as your FreeNAS git user, you may follow my previous post “Creating a secure Git repository server” to setup the git repository.

Converting a MediaWiki database from MySQL to SQLite

So the plane here is to convert a fully working MediaWiki install running on MySQL to run on SQLite instead.  To do this you will need to install a 2nd MediaWIKI install on a test or development system.  Once you are done you can move your new MediaWiki install to where every you would like.

Backup up your Old MediaWiki Installation

To start, from within your working MediaWiki install, first back up your data.

php maintenance/dumpBackup.php --full --uploads > wiki-backup.xml

This will create a file named wiki-backup.xml in your MediaWiki’s root directory, copy that file to a safe place.  We aren’t going to touch the MySQL database until were done, but it’s always a good idea to have backups safe and sound in case you need them.

The backup script run above dose not backup your MediaWiki’s uploaded images and other files.  These files are stored in your ‘images’ folder in the root of MediaWiki’s directory.  You need to back those up also.

tar -czf wiki-images.tgz images/

You should now have everything you need from your old MediaWiki install. Next you will need to install MediaWiki in a new location on your sever (or a development server).

Installing your new SQLite MediaWiki site

You should download and install the newest version of MediaWiki.  I always you the development trunk since this is what’s used on Wikipedia.

During the install process you will be asked what database you would like to use, you much choose ‘SQLite’ since this is the point of reinstalling MediaWiki.  Bring your new install all the way so you have a new install running on your server.  MediaWiki will create a default home page for you and you should be able to modify that page.  If you are unable to get MediaWiki installed or if you have a problem modifying the Main Page after the install, please see the MediaWiki mailing lists or the FAQ for assistance.

Restoring your Data on your new SQLite site

After you have your new SQLite version of MediaWiki installed and working, you need to restore your data.  The database part of this is pretty strate forward.

Start by copying the xml file you created in the first step to your new MediaWiki install.  Then run the following:

php maintenance/importDump.php wiki-backup.xml

Depending on the amount of pages you have, this may take quite some time to process. Once this is done all your pages should be on your new install (expect the Main Page, you will need to copy that manually).
To restore you images and other uploaded files, first you need to extract the tarball you made earlier to temporary location.

mkdir temporary
cp wiki-images.tgz temporary
cd temporary/
tar -xzf wiki-images.tgz

This will create a bunch of folders in the temporary directory, you need to copy everything in those folders into a single folder. The name of the folder doesn’t matter, I’m using tempimages, but you may use what you would like.

cd ../
mkdir tempimages
cp temporary/images/*/*/* tempimages

Now that you have everything in a single folder, import the content of that folder into your new MediaWiki install.

php maintenance/importImages.php tempimages/

And that should do it, you should now have a fully working MediaWiki install using SQLite.

Enable SSH Key Authorization on FreeNAS

FreeNAS is a powerful tools for archive data and other long-term storage requirements. Recently I have started backing up this and other off-site servers to one of my local FreeNAS boxes. Since these systems are only connected via the insecure internet (no VPN), I decided to transmit the backup files via SSH using SCP.  In order to do this without having to enter my password in for each and every backup (most of which happen while I’m hopeful sleeping), I needed to implement SSH Key Authorization on the receiving FreeNAS box.

To do this first I needed to create a DSA key pair on a different system.  On my Fedora 12 laptop I ran

ssh-keygen -t dsa

The trick here is to not create your new key pair in the default directory of “~/.ssh/” but in a temporary directory instead. So when it asks you.

Generating public/private dsa key pair.
Enter file in which to save the key (/root/.ssh/id_dsa):

Enter a different file in witch to save the key in. Note this is asking for the name of a file, not the name of the directory, it will also create a .pub file, this is the public key for the above private key.

Now that you have a public/private key for the FreeNAS box, if you don’t already you need to create one for the user that you plan on sending the file from.  Just follow the above command, but this time, you may just hit enter all the way threw leaving all options as default.

Next, go to your FreeNAS web-page control panel, If you don’t already have one, you will need to create a user on your FreeNAS box for you to connect to.  You may do this via “Access -> User and Groups” from the black bar on the top of the page.

Now from the top (black) bar go to “Services -> SSH”

On your Services|SSH page, first make sure the service is enabled (top right hand corner). Once it is you will be able to change the below options.

  • TCP Port: The default (port 22) is fine in most cases, but note if you change it, you must use the new port for all connections.
  • Permit root login: My option is that the root account should never be allowed to log in via a remote process.  You should set your system up correctly where this is not needed.
  • Password authentication: For now this must be enabled (checked), once you have set “Key Authorization” up, you may disable this option.
  • TCP forwarding: Disabled (unchecked)
  • Compression: Enabled (checked)
  • Private Key: This will be were we put the private key created above.  All you need to do is copy and paste.
  • Extra options: Blank

After you have made your changes, “Save and Restart” the service.

On your local system, you need to copy the content of the local users public (~/.ssh/username.pub) key file to a new file named “authorized_keys” (Note: this is not the file we created for FreeNAS but the file we created for your local account).  This is the file that will need to be copied to your FreeNAS box.

Now that you have all the needed bits, we need to log into your FreeNAS server and create a “.ssh” directory to store the “authorized_keys” file.  To log in to the FreeNAS box interactively run a command similar too.

ssh freenasuser@freenasaddress

Or if you changed the “TCP Port” above, your command will look like this:

ssh -P freenasport freenasuser@freenasaddress

Once your logged in, you need to create the directory, by doing.

mkdir ~/.ssh

After you have successfully created your directory, you may exit out of your FreeNAS box for the next step.
Back on your local system you need to copy the “authorized_keys” file created before to the FreeNAS box. Using SCP you can do this by running a command like:

scp -P freenasport authorized_keys freenasuser@freenasaddress:~/.ssh/

This will copy the file to the FreeNAS box. Next, reconnect to the FreeNAS box as you did before and run.

cd ~/.ssh/
chmod 600 authorized_keys

Once your done, you should be able to connect to your FreeNAS box using the private key in the authorized_keys with out a password.