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 username@deploymentninja.com 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!

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