GIMMC, Global Internet Multimedia Center is a linux distribution designed as a back end server to feed XBMC or Plex front end media clients. It comes with Couch Potato, Headphones, Sickbeard, and Maraschino preinstalled and running at start up ready for your configuration. It comes with all the tools you need to build and organize your collection. XBMC 12.2 is also installed should you wish to use this distribution as a front end client for an all in one HTPC setup. Popular file sharing tools also included. This linux distrubtion was built in response to reading various support forums of people struggling understanding how to install these great opensource projects are there own. In the future I plan to release a front end distribution as well with xbmc preconfigured with popular addons for live tv and media tagging.

This Linux distribution was built with suse studio which will allow anyone to copy edit and test in a virtual machine via their site for free. Provided downloads include bootable flash drives, preload, and a live cd. 
Downloads are located at  http://susestudio.com/u/psiegel

All Web Applications are running on their default standard ports:
CouchPotato:5050
Maraschino:7000
Sickbeard:8081
Headphones:8181

e.g. locahost:8081 to access Sickbeard.

*nix machines have been able to run software on a remote machine and display the GUI locally for decades. I'm always surprised to learn how many system admins are unaware of these features or didn't realize this could be done on windows , not just unix platforms. This is great for system admins as well as standard users who need access to specific linux applications , but lack the background information to navigate the system. Why not just use VNC? VNC is great , but many people frown on VNC because of potential security issues if VNC isn't setup correctly.

Windows users need two pieces of software: an secure shell program (ssh) to establish the remote connection and an X Server to handle the local display. For ssh on windows I will always recommend Putty. It's free and extremely versatile as well as cross platform which I also strongly support. Xming to my knowledge is the leading open source easy to configure XServer for Windows systems.

Putty is available at the following link: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

Most users will only require putty.exe, I would recommend using the full windows installer.

Xming X Server for windows is available at the following link: http://sourceforge.net/projects/xming/

Once Xming is installed on your machine all that is required is to start it. Once launched it will display a X icon in the task try next to the system clock.

5. Expand the 'SSH' tab from the 'Category' list
6. Choose 'X11' from 'SSH' list
7. Check 'Enable X11 Forwarding'

6. Click open
7. Enter your username and password for the linux system
8. Start the app as you would from Terminal on the local system
9. Enjoy!

X Forwarding can also be accomplished using native tools of Mac OS X+.  Mac users need to run "Applications > Utilities > XTerm". In a command line terminal run "ssh -Y [email protected] application_name

by Paul Siegel

A common theme of this blog is offering  large scale solutions on a budget. In these tough times many organizations are evaluating Google Apps as cost effective replacement to in house e-mail solutions. For organizations running Active Directory many are turning to Google's recently released Google Active Directory Sync tool or NetIQ's Gmail Connector for NetIQ Identity Manager(formally Novell IDM) for safely moving users passwords from their domain to the cloud. Some smaller organizations don't have the luxury of these higher directory solutions either due to cost or environmental factors, which is what makes Google Apps appealing in the first place. There is another opensource solution that often seems overlooked. Google Apps Directory Sync Tool supports OpenLDAP with password sync without making the userpassword a plain text attribute. This configuration uses only one tool for creating , deleting , suspending , and password synchronization from your openLDAP directory to your Google Apps Domain. 

Google offers excellent documentation of Google Apps Directory Sync Tool located here:
http://commondatastorage.googleapis.com/enterprisetraining/gapps/admin/DirSync_GoogleApps/en/DirSync_GoogleApps.html

Should one decide to investigate this route there are some basic openLDAP configurations to be aware before attempting to sync users.

Default configuration of openLDAP will not have a password policy. User objects created will have a clear text password unless specified during creation. For this scenario we will need passwords to be hashed by default.

 Open your ldap server configuration utility. Accessing  this utility varies per Linux distribution  In Opensuse open yast then Ldap Server. Expand out the database arrow on the left, then expand all options beneath it. You will see your domain listed. In the example pictured below it will be dc=test,dc=edu. Highlight Password Policy Configuration to bring the menu forward and check "Enable Password Policies" and "Hash Clear Text Passwords"

This will ensure that all passwords in the database are hashed at all times. The default hash in openLDAP 2.4 is salted sha (SSHA).

While our password policy ensures all passwords are hashed by default, openLDAP  uses a Google Apps unsupported hash. The resolution to this problem is to force a new default. This is done through editing the cn=config. The cn=config is the replacement to the former slapd.conf in previous versions of openLDAP. It is a file ldif database that allows configuration of the directory without having to restart the service. The cn=config is most easily edited with a ldap browser. To configure,  you must do an ssl bind to the directory using cn=config as the Bind DN and the Base DN. Before this can be accomplished, Simple Bind to the cn=config database must be temporarily turned on to allow editing. This is done through the Ldap Server utility the same way as the password policy. Under databases there will be a section for cn=config with enable Simple Bind as it's only option.

While it seems concerning to allow plaintext authentication, this connection can only be established remotely over ssl and is only turned on temporary when editing the cn=config.

Next we have to configure our ldap browser connection. I personally prefer Apache Directory Studio for it's ease of use and ability to easily fetch operational attributes of objects. In your ldap browser add a new connection.

This configuration can only be done over ssl default port 636.

Select Simple Authentication and set Bind DN to cn=config. Apache Directory Studio offers a Check Authentication button to test settings before moving forward.

Uncheck Get base DNs from Root DSE and specify cn=config as the Base DN.

The connection end result will look like this with only the config object available as you're bound directly to it. Expand out cn=config in the LDAP Browser window and then right click and select New Attribute in the white space of the editor window.

From the Attribute Type drop down menu select olcPasswordHash and click Finish.

Click in the value cell of the editor to add a value to the attribute. Google Apps Directory Sync Supports {SHA},{MD5}. For this example I'll use {MD5}.

Go back into your ldap server utility one last time and turn off Simple Bind.

Your OpenLDAP directory is now configured to hash all user passwords to MD5. This will allow your Google Apps Directory Sync Tool to retrieve encrypted passwords from your ldap directory over ldap ssl. Google Apps Directory Sync Tool is available for Windows, Linux and Solaris, with configurable run options giving you the ability to run this tool as a cron job. This particular Google Apps deployment can be a one-server solution. Consider evaluating this solution. you may be surprised!

Microsoft Windows 8 will be available to the general public soon enough. I was fortunate through work to receive a copy of the Windows 8 Enterprise RTM.  I installed on a lower end machine I have for development and went about the standard install checking out what baseline drivers looked like , how profiles are handled , typical new operating system exploration. What happened next surprised me. The same week I was give an old box that someone was no longer using with a little better specs than my current development machine. Bare bones rig with an amd phenom. Nice upgrade to my current Intel core 2 duo. I moved my video card , hard drives , and ram over the new machine. I pulled out my windows 8 flash drive with the intent to reinstall on my new hardware. What happened next surprised me. I booted the machine and windows 8 actually loaded. The machine launched with a setup screen and proceeded to install new devices. Windows 8 actually changed hal and obtained the new device drivers and came back to life on it's own. I logged in to my normal profile and activation remained intact. Knowing about Windows to go I shouldn't have been surprised by this event , but Microsoft actually got something right. Now take this information and think about recovering workstations and your business model. No longer do we have to image and prepare a replacement machine, move user data and interrupt a half day of productivity to get a down machine back to the user. IT support is moving one step closer to that dream of leaving at 5:00 and enjoying weekends off.

One of the greatest advantages to using Microsoft for Imaging is the ability to perform offline image patching and keep images up to date rather than rebuilding your base image every time a major update or service pack is released. Deployment Image Servicing and Management (DISM) is the command line used to carry out these functions. If beginners  are more accustomed to other tools like Ghost Explorer or ZMG Explorer, then GUI DISM will make you feel right at home.

DISM GUI can downloaded from Mike's Blog at  http://mikecel79.wordpress.com/2011/11/30/dism-gui-3-1/

 Create a folder for use as a mount point and then launch GUI DISM. Select the image file you wish to update under the Wim File heading and the folder you created under the Mount Location Heading. Then click Mount WIM. You should recieve a success message in the DISM Output pane.

Select the Drive Management Tab to the right of the default tab (Mount Control.) To add drivers to your image they must be extracted to their lowest .inf form, not as an executable. In the Add Drivers area select the folder where your drivers have been extracted. Check 'Force Unsigned' if necessary for the driver. In the image below the driver files to the left are an example of extracted drivers.

Click Add Drivers and the following window will appear:

This may run for some time depending on how many drivers are in the folder that was selected. You will know it has completed by watching the DISM Output pane. The DISM is Running progress window will close and the Output will look something like this:

Switch back to Mount Control tab and click Dismount Wim. You will be prompted asking if you want to commit changes to the wim. Select Yes and the wim image will be updated with the drivers you've chosen to inject into the wim. If you realize a mistake at this point you can select no and changes will be discarded. 

Again the DISM is Running window will appear for a while and once complete check the Output pane for any final error to make sure the operation completed successfully and wim is dismounted.

GUI DISM is a great tool for those who have not yet achieved "Zero Cool" status with a command prompt. Adding windows updates is completed using the same process under the Package Management tab. For updates this tool allows the injecting of .msp (windows installer patches) and .msu (microsoft updates) Thanks to mikecel79 for this great tool and please check out his blog at  http://mikecel79.wordpress.com/

A lot of schools with lab environments that are often composed of donated outdated equipment have had their IT staff busy over the past few years trying to extend equipment life and squeeze blood out of lemons. We've read  various success stories about Linux deployments to help make older systems skate a few more miles before they're put out to pasture. The real problem with Linux for most is being able to manage the systems' deployments remotely and efficiently,  and making that management simple enough that it doesn't require an onsite developer to keep the fleet afloat. A suggestion to be explored for me surely would be Linux Terminal Services Project (LTSP). Using LTSP we could PXE boot a lab of 24 computers from one imaged master computer and then remotely manage from 1 machine. Any software updates , patchings , or image changes could be done to one computer in a lab and take an effect immediately on the others pending a restart. 

For this demo I'm going to use OpenSUSE 12.1 for multiple reasons. I personally believe that using their WebYAST package manager to administrate the server remotely is ideal for this environment. OpenSUSE LiFE (Linux for Education) has LTSP tools built into the distribution with lots of documentation for beginners, and finally it will show workings similar to SUSE Linux Enterprise Desktop. Also, since most of the schools I've encountered are Novell shops already, it makes sense to stay with the support vendor from which you're already buying other products. Plenty of Linux distributions offer support and documentation for LTSP most notably Edubuntu. Please use whatever distribution you are most comfortable with in production. This demo will be displayed using only the open-source tools.

Install openSUSE on what will be your Master computer in your lab deployment. Stock SUSE is available from  http://software.opensuse.org
OpenSUSE LiFE is available from http://en.opensuse.org/openSUSE:Education-Li-f-e

Install and configure the software you will require for your environment just like you would for any other linux lab deployment. in SUSE this is accomplished through the YAST package manger. Also set up your user authentication. It will support local users , ldap, or windows domain. You will need at least 1 login available per terminal.

Install Kiwi-LTSP on your master computer. It is available from  http://en.opensuse.org/Portal:KIWI-LTSP as a 1-click install that will auto-launch YAST, set up the repository, and complete the install for you. If you are running Opensuse LiFE this is already done for you.

Once you are ready to deploy your image to your client computers, Open the Gnome terminal.

Type su -
You will be prompted to enter the root password.
This will switch to the superuser and allow you to start the PXE service.

Type kiwi-ltsp-setup -p
This will check to verify we have all the perquisites installed for kiwi-LTSP. If any are missing it will locate them from your installed repositories and automatically install them for you. 

Type kiwi-ltsp-setup -c
This is referred to as the 'configure everything' script. It will generate your boot images as well as set up your PXE/TFTP services based your network configuration. 

After pressing enter the script will execute. You will know it has succeeded when the ======Setup Completed====== is displayed.

Now we start our client machines and set them to PXE boot. They should then automatically receive the boot image from the LTSP master computer. It will boot through a GRUB menu and arrive at the kiwi-LTSP login screen.

Login with a user account that you already created in the master computer.  You will see the Computer image you built fully setup and deployed to the workstation with excellent performance. The client computer image is running completely in RAM and will be reset back to the same state as the master as soon as the student logs off.

There you have it. A fully deployed computer lab of linux machines functioning when you have only touched one physical machine in the computer lab. Now, since this is a SUSE machine we can handle patching , software changes, and user accounts remotely using webYAST (pictured left) or over SSH via traditional yast. Some additional configuration will be needed to enable webYAST, and that documentation can be found here:  http://en.opensuse.org/Portal:WebYaST
Splash screens for GRUB as well other custom PXE options can be created by running the command easy-ltsp on the master computer.  Easy-LTSP is a GUI program used to help you manually edit LTSP configuration files for customization.

Different versions of kiwi-LTSP and easy-LTSP have different network requirements. This demo was created using version 0.5.247.18974. For additional information on network configuration check out the documentation at : http://en.opensuse.org/SDB:LTSP_quick_start_12.1_Edu#Configure_Network

A Preconfigured virtual appliance can be downloaded from Suse Gallery at:
http://susestudio.com/a/wc0u6V/gianni-s-ltsp-server 

Every good computer nerd has a few live cds in their bag of tricks for emergency triage , virus removal , data recovery , and just plain fun. Some prefer Linux others WinPe. Imagine if you had a full copy of Windows with you that you brought every where you went. Not virtual but real Windows, All your programs, your profile , and your tools all at your disposable. Or better yet have a flash drive to hand to CEO's secretary for him to boot off while you take his hard drive and clean out that pesky virus he keeps finding. In Windows 8 Microsoft has made this a reality. This isn't some future innovation we will never see like Steady State for Windows 7. This is something that we can build right now with our Release Preview DVD's that  we've been drooling over for the past month. Still don't believe me? Check out this youtube clip from a developer that was at the Microsoft Build Conference:  

What we'll Need:

A Machine Windows 7 or Windows 8 with the The Windows Automated Installation Kit (AIK) Installed.
 
The install.wim image from the Windows 8 Release Preview ISO

A USB flash drive (Preferably 32gb or more , but a 16gb will work, just not very well)

Step 1: Gather Our Tools

Install the Windows Automated Installation Kit located at: http://www.microsoft.com/en-us/download/details.aspx?id=10333  if you do not already have it installed.

Create a folder to use as our working directory for ease of access. I prefer c:\wintoflash.

Insert your Windows 8 Release Preview disc (I've only tested with 32bit) and located in the sources directory on the root of the disc is a file called install.wim. Copy that to your working directory. (c:\wintoflash)

Next navigate to C:\Program Files\Windows AIK\Tools\x86. We'll want to copy the imagex.exe and bcdboot.exe to our working directory (c:\wintoflash) If bcdboot.exe is not located in this folder then it can be copied from C:\windows\system32\

Now we've assembled the tools we'll need to build our bootable flash drive.

The Flash drive needs to be partitioned and formatted to make a bootable NTFS drive. So we will have to run diskpart from an administrator level command prompt to prepare the drive.

Navigate to cmd in the start menu and right click and run as administrator to open the properly elevated cmd window.

Type Diskpart

The prompt will display DISKPART> at the bottom. Type LIST DISK to find the flash drive's disk number.

Type SELECT DISK 3 (or the number you discovered is your flash in the above step)

Type Clean this will erase all existing partitions on the flash drive.

Type CREATE PARTITION PRIMARY to create a new primary partition on the disk. you can verify this step by typing DETAIL DISK

Type format fs=ntfs quick to make the filesystem ntfs

Type ACTIVE to set the partition as Active for booting.

Type DETAIL DISK again to verify actions

Type Exit to leave diskpart utility

Step 3: Image(x) the Flash Drive 

Change directory to the working directory we created earlier by typing cd c:\wintoflash

Type imagex.exe /apply c:\wintoflash\install.wim 1 I: (I: is the drive letter of the flash drive yours may be different). 

Once the wim imaging is complete it's time setup the boot record by typing   c:\wintoflash\bcdboot.exe I:\Windows /s d: /f ALL

Step 4: Reboot and Enjoy 

That's it , you've created a portable windows 8 USB stick. On first startup it will prompt you for your windows 8 release preview cd key that came with your download. Each time you boot this flash drive in a new computer it will probe and install device drivers and take a while to boot up. Each boot after on that same hardware will be much faster. I look forward to a world where I can hand the  contractors that my boss hires an RSA key fob and a bootable flash drive and  let go about their merry way only to replace the two should something go bad. All new operating systems have the good and the ugly but this is one feature I am certainly looking forward too!

This tutorial assumes you have Arma II: Combined Operations installed from steam and have launched both Arma II and Arma II:Operation Arrowhead to install the directx and battleeye dependancies.

Download the Six-Updater from https://dev-heaven.net/projects/six-arma-updater/files

1. Run the Six-Updater exe file to install to the updater and launcher.
2. Run the Six Launcher from the desktop shortcut and you should see a DayZ logo at the top with a server list to the right. Click the Update button on the left.
3. When update is complete, close the launcher.
4. Launch Steam and go to your games library, in the bottom left below your games list you find a button called "+ Add a Game..." Click here

5. Click browse and navigate to the directory where you installed six-updater. Default 64bit Windows 7 is C:\Program Files (x86)\SIX Projects\Six Updater
6. Select Six Launcher.exe and then click add selected program.

7. A Shortcut for Six Launcher will now appear in your Games Library listings.

8. Right click on Six Launcher and select Properties. change the first field Six Launcher to Day Z or desired game display name. You may also change the icon to another file. Verify the the target and start in fields look similar if not exact to the following:

9. Launch Day Z from your Game Library and the Six Launcher menu should appear with a verify button on the left and server listings on the right. Click the "Verify" button so that Six Launcher will verify your local game content. The verify button should automatically change to "Launch" select a server from the right or click launch and use the in game server browser. Once in game you should be able to use "shift + tab" to access the steam overlay features as well as track your time spent playing the game.

Funding for IT is at an all-time low.  If you have "champagne taste" but working with a "beer budget."  Microsoft Deployment toolkit is the way to go.  Lucky for us, the prompt-happy "Lite Touch" can be tailored into a much less intense experience if you follow the following process. 

There at least 13 menus throughout the deployment wizard and we need to remove them all in order to automate! Lets start by skipping the Welcome and User Credentials screen.  We need to edit the bootstrap.ini for the deployment share.  In your workbench, go to "properties" of your open deployment share and select the "rules" tab  so removing them is required for automation (see below).

The default boot settings.ini will look something like this:

[Settings]
Priority=Default

[Default]
DeployRoot=\\DeployNinja\images$

Time to feed the monster its first can of answers.  All you have to do is add in the following line: SkipBDDWelcome = Yes to the bootstrap.ini to bypass the Welcome screen. The user credentials prompt is skipped by adding the following lines for the user account:

UserID=Ninja
UserPassword=Passw0rd1
UserDomain=DeployNinja


This account can be a domain account or a local server or workstation account depending on your setup. For this tutorial it is a local server account. The completed Bootstrap.ini file will look like this:

[Settings]
Priority=Default

[Default]
DeployRoot=\\DeployNinja\images$ 
SkipBDDWelcome = Yes 
UserID=Ninja
UserPassword=Passw0rd1
UserDomain=DeployNinja 

Once the bootstrap.ini has been edited the boot image will need to be regenerated in order for the bootstrap.ini it be copied into the deployment boot image. This done by updating the deployment share from the menu in the top right corner of the deployment workbench. In the end, when the litetouch.vbs script is executed you will bypass the first two prompts and arrive at the task sequence menu. See the images below for the end result.  Keep in mind that anytime you edit the bootstap.ini you will need to regenerate the boot images,

Since the primary goal for the most of us is to eliminate the need to enter a password, this will be the end of the road for some.  From this menu, a user can choose the desired software to install or choose to refresh the image on their computer. Others, however, prefer the ability to re-image machines from the ground up on a regular basis.  This is where Deployment Rules come into play. Back where we accessed the bootstrap.ini there is a set of rules to further fine-tune our deployment. 

Above is the predefined set of rules for our deployment share for the default installation.  From here we have the ability to customize the prompts that appear during the task sequence OR add additional functionality.   Below is an example of a custom rule set for a fully automated single task sequence.

[Settings]
Priority=Default
Properties=MyCustomProperty

[Default]

OSInstall=YES
SkipAdminPassword=YES
SkipApplications=YES
SkipAppsOnUpgrade=YES
SkipBitLocker=YES
SkipCapture=YES
SkipUserData=Yes 
SkipComputerName=YES
OSDCompterName=%SerialNumber%
SkipProductKey=YES
SkipComputerBackup=YES
SkipDeploymentType=YES
DeploymentType=NEWCOMPUTER
SkipDomainMembership=YES
JoinDomain=stinkycheese.deploymentninja.com
DomainAdmin=Administrator
DomainAdminDomain=stinkycheese.deploymentninja.com
DomainAdminPassword=Passw0rd1
SkipFinalSummary=YES
SkipLocaleSelection=YES
KeyboardLocale=en-US
UserLocale=en-US
UILanguage=en-US
SkipPackageDisplay=YES
SkipSummary=YES
SkipTaskSequence=YES
TaskSequenceID=BASE64
SkipTimeZone=YES
TimeZoneName=Eastern Standard Time

The real advantage of adding these rules in is that, if you want,  you can control how involved the user is in the task sequence. if you want the user to choose their computer name then you would change the line SkipComputerName=YES  to SkipComputerName=NO and the user can choose  the serial number as the computer name or something they specify. If you want to specify some of the settings but allow the user to pick the task sequence then remove the lines SkipTaskSequence=YES TaskSequenceID=BASE64, DeploymentType=NEWCOMPUTER. 

DeploymentType can have multiple options: the REFRESH option is used when executing the litetouch.vbs script inside of windows. NEWCOMPUTER would be used for deploying from Windows PE (Windows Deployment Services or LiteTouchPE.iso). 

Applications can also be added to the rule set to install across all task sequences without having to go back to edit them individuality by adding:


MandatoryApplications001=[guid of desired application]


The guid is automatically assigned to the application when the object is created in deployment workbench.

Domain Membership is not a requirement. If you choose to skip joining the domain you may also specify a workgroup=Ninjaland or You may also choose a specific OU in the domain by adding:

MachineObjectOU=OU=assasins,OU=Ninja,DC=local 

 The customization is limitless and once you have a working automated deployment share there are endless means of executing your task sequences even without a pxe enviroment. For example one could use psexec to launch the litetouch.vbs on a remote machine or create custom shortcuts in the start menu that point back to the deployment share for a self service image scenario.  Happy deployments mean happy bosses , cheap deployments mean happy board members.