Google Apps Active Directory sync.

Are you planning to migrate from MS suit to Google Apps?

Some time back I did one such migration and came across several posts where people said "Google AD sync doesn't work properly", etc etc.

But I found it very useful and usable, with a fact that not much of the documentation is available around it.

This lack of documentation inspired me to write this blog, hopefully it will ease up your work.

To begin with, you need to have:
* Working MS AD and an account with Google App
* Administrative credentials for both (AD and Google App) accounts.
* "Google Apps Directory Sync tool" installed on your system.

Now lets see how it is done:
* Start the "Configuration Manager" from your startup menu.

* Fill the required details as shown in screenshots.

General Settings: Check the options that you want to migrate to Google Apps. In my case I used only Users and Groups.

Google Apps Settings: Fill the email and password of user with Administrative privileges on Google Apps.

LDAP Connection: This part needs your local LDAP/AD details. The provided user nay not be admin, but needs only read access.

User Attributes: Provide the local (LDAP/AD) attribute for mail ID (in my case it was mail).

User Extended Attribute:  This configuration maps local given name, sir name and password attributes to Google Apps.
Specifying Suspension Policy enables the user to decide what to do if a user is present in Google Apps and not in local AD.

User Sync: Add a new rule. This rule will define which users to sync (or which user not to sync). The rule field accepts RegEx, allowing us to add multiple users through one line.

Notification: In this section define your SMTP server and other details required to relay email on success or failure of this sync up.

Sync Limit: This section is to specify the suspension limit. In simpler words "The script should fail if more users are being suspended (than the specified limit)".

Log File: Specify a valid log file path here. The sync tool will save its output in this file.

Anything Else: There are many more options available (example syncing contacts etc), but in this blog I documented only the minimalistic configuration (and that was what I required fro my project).

* Test it out.

Simulate Sync:  This tab will tell you if your configuration is correct. And if you don't find any error (warnings are still OK), then just hit "Simulate Sync" @ the bottom.

Result: Hitting Simulate Sync will take you to a new view. Check if you see users being synced and you don't have errors.


* Save this configuration to a file. I saved it as google-sync.xml.

* Run it: As of now this sync can only be run through command line, so just run this command and see the magic.

sync-cmd.exe -a -c "google-sync.xml" -r C:\Sync-logs\Google.Sync.logs

* Schedule it with the help of tool like Jenkins and you are done with one aspect of migration which gives head ache to people.

PS: Scheduling it through a tool makes it easy to monitor and/or run it on demand.

I am confused (Google docs Vs Dropbox)

One of the interesting thing that I worked recently on was a small decision of either using Google docs or Dropbox for storing and sharing documents.

Seems unimportant?

I also thought the same on hearing this for the first time, but believe me this proved to be an interesting study.

Let me take you to the tour of both.

Google docs is an online solution provided by Google to collaboratively work (sharing, editing, etc) on the documents.
  Several addons like Cloud Connect, etc helps us to sync our native MS office documents to Google docs.
One of the advantage of Google docs is that multiple people can edit one single document @ the same time.

On the other hand Dropbox is used to share files, irrespective of the file being a document, image or some thing else.
Same account can be either synced to multiple computers OR same files can be shared to multiple accounts, hence giving feasibility of accessing the files across the globe (on multiple systems).
Feature like sharing and selective sync help us selective share our files with different people.
One of the advantage of Dropbox is the ability to share all sorts of files (not only just documents)

And the confusion starts :-)

It looks pretty simple that Google docs should be used for documents and Dropbox for other files, but the problem statement lies in the fact that Google changes format of our existing MS office/Open office  documents to Google docs format (on uploading). In most of the cases this is not an issue, but it created trouble when you have formulas, macros and images in your documents, as
"They may disappear from your uploaded document".
Google also provides a solution to this, in the form of uploading the documents (in this case other files can also be uploaded) in original format (not changing the format to Google docs format).

Here comes another "BUT".

But this also has a drawback, that we can't maintain single source of truth for the documents. To edit any document we have to download it and then again upload, which creates multiple copies in Google docs (which have to be manually deleted).

Conclusion after digging deaper:
Using any of these tool is subjective.

IF:
* You are creating the documents from scratch.
* And the priority is to have simulanious editing of documents, rather than maintaing MS office formatting, example: Attendance sheet etc.
Then Google docs is THE tool.

ELSE IF:
* You want to use your existing docs.
* And the priority is to use the MS office format.
Then Dropbox is THE tool.

Advantages:
* Google can save money sent on MS office licenses.
* Both the tools can save the hassle of maintaining local shared file server.
* Both have there recovery mechanism, so no danger of getting fully F**k*d.
* Both provide full fleged files/documents sharing system (sharing sccross the globe).
* Both provide the confidence of having one single "Source Of Truth" for documents.
* Dropbox provides offline editing of files (as they gets synced when connected back to internet). Same is provided by Google docs when used with Cloud Connect.

As my requirement was more of sharing and offline working, so I choose Dropbox for now :-)

Cross Platform scripting with bash.

Is this title a bit confusing?

I asked this question to many people and got the same answer as "YES"
In our day to day life when we talk about bash, we refer to Linux as it's OS.

But the main punch of this blog is to mak BASH break the boundaries of Operating System.
I agree that till now bash is not capable of doing this alone.

Now any guesses about the tool?

If you guessed "CYGWIN" then consider yourself as winner ;-)

To make it more clear for people who were not able to guess it, I can put my example here:

Background: I am a consultant and work with all sorts of projects, during my last couple of projects I was automating build & release cycle for a product that is built on four platforms (Linux32, Linux64, Windows32, Windows64), hence I was desperately looking for some cross OS/platform scripting solution.

My Thoughts: I am a BASH guy and as any developer, my first preference was to look for a solution around what I already know, rather than straight away jumping into any new technology and learning it (it was my second option though).
If it was not bash then I was looking into ant or others to do the job.
As
"The best way to do a work, is to do it." --Harpreet Singh

For Newbies: Cygwin is Linux-like environment for Windows making it possible to port software running on POSIX systems (such as Linux, BSD, and Unix systems) to Windows.

Solution: Now lets put this together.
Install Cygwin on a windows system with basic features like "openssh", "vim", etc.
That's it you are ready to rock 'n' roll.
All most all your Linux commands can run in this shell, which includes doing "ssh" into a Windows system ;-)

Need More: The story is not over yet. Combining the above setup with a CI tool (Jenkins in my case), gave me what I wanted.
A full fledged automated build system, running on four platforms simultaneously (using Jenkins' multi configuration project feature), with ease of writing the script only once and that too using BASH.

Now that's what I call a win ;-)

The winners prize: As a prize of my effort done for the above setup I got:
* Time saved per build/release cycle.
* Time saved in developing automation scripts.

And more important a "Happy Client"