Posted by Mike
Wed, 29 Apr 2009 13:09:00 GMT
Amazon's EC2 service now includes a number of Windows Server 2003 images, starting at $0.125 per hour. These Microsoft sanctioned images are a great alternative to the QEMU shenanigans from the past.
One of the advantages of Amazon's EC2 service is the ability to provision virtual machines via scripts, and without human interaction. Here's a description of my approach to bringing an instance of Active Directory online via script.
Prerequisites:
- Amazon EC2 account
- command line RDP client (e.g. rdesktop)
- dcpromo answer file (I found Daniel Petri's article helpful)
Your RDP client will need to support two features: file sharing, and remote script execution. I've found the Mac RDP clients tough to use via script, but Ubuntu's rdesktop works just fine in a VirtualBox VM.
Starting the Windows Server VM
Choose the Basic Microsoft Windows Server 2003 image or the Basic Microsoft Windows Server 2003 with Authentication Services image; a small standard instance type should be sufficient.
(The Firefox elasticfox EC2 plugin makes it easy to manage windows instances.)
Once your instance is online, you'll need the public DNS name and administrator password for the instance.
Installing Active Directory
Normally, AD is installed and configured by running dcpromo and working through the relevant dialog boxes. Unattended installs are supported via the /answer argument:
C:> dcpromo /answer:%path_to_answer_file%
Running this command on an EC2 instance poses two challenges: how to run a windows command remotely from a script, and how to copy our dcpromo answer file from our local host to EC2. Fortunately RDP solves both problems. Using rdesktop one can define a script to run on session startup, and a local folder to share with the remote host.
Install Active Directory remotely using rdesktop as follows:
mpierson:$ rdesktop -r disk:share=/home/mpierson/winshare/ \
-u Administrator -p <admin_password> \
-s "dcpromo /answer:\\\\tsclient\\share\\dcpromo.install" \
<windows_hostname>
where /home/mpierson/winshare/dcpromo.install is the local path of the dcpromo answer file for your AD configuration. (The RDP file share defined by the -r argument will appear in the Windows host network share list with a host name of tsclient.)
FWIW, here is an example answer file for dcpromo.
Access Your AD Domain
Use rdesktop to access your new AD domain as follows:
mpierson:$ rdesktop
-u Administrator -p <admin_password> \
-d <win_domain_name> \
<windows_hostname>
where win_domain_name is the DomainNetBiosName defined in your dcpromo answer file.
Posted in technology | Tags activedirectory, ec2, windows | no comments | no trackbacks
Posted by Mike
Tue, 28 Apr 2009 16:37:00 GMT
Oracle has made a number of their products available for use on Amazon's EC2 service. Unfortunately, each instance of their 10g XE RDBMS image must be configured manually via ssh before use.
Turns out that the 10g XE image hijacks the bash profile script to force manual configuration. If one was motivated to enable unattended configuration of the image, the bash profile script could be un-hijacked with scp:
mpierson:$ scp -i EC2_KEY my-bash-profile.sh root@<EC2-HOST-NAME>:/root/.bash_profile
BTW, the hijack script overwritten by scp above is also a good starting point for an script that would bring the database online in an unattended scenario. Here's what it does:
- force acceptance of Oracle EC2 license
- force change to oracle system user
- set Oracle environment, including host name
- force change to SYSTEM and SYS oracle db accounts
Posted in technology | Tags ec2, oracle | no comments | no trackbacks
Posted by Mike
Sat, 25 Apr 2009 02:16:00 GMT
An IdM customer recently found themselves in a pickle: they wanted to integrate additional resources into their IdM deployment, but did not have access to the original configuration files or CBE.
Here are the steps we took to extract configuration from their production repository:
- export configuration from running system via lh
- split export file, one file per top level element
- mangle XML objects (remove date based attributes, GUID etc)
- repeat above for reference, out-of-the-box, IdM deployment
- diff XML object sets (custom deployment vs. reference deployment)
And the details...
Export Configuration
Use the lh command to extract the running configuration:
mpierson:$ export WSHOME=/var/lib/tomcat/webapps/idm
mpierson:$ $WSHOME/bin/lh console -c "export /tmp/export.xml"
Note: the export process may take some time, and consume significant cycles on the host and the repo; the resulting export.xml file will be of the order of 100Mb, depending on the number of user/resource accounts.
Split Export File
To facilitate comparison of the custom configs to the reference deployment, split the export file into many files, one per top level waveset element:
mpierson:$ xsltproc split-waveset.xslt /tmp/export.xml
We used a simple XSL transform that writes each child of the top level waveset element to a file, using file names based on name or id attributes, if available.
Note: the example XSL transform will write the files to a directory called 'split', and there will potentially be many files created.
Mangle XML Objects
Again, to facilitate comparison of the custom config objects to the reference deployment, we mangled the split XML files to remove date based attributes, owner/modifier attributes, and GUIDs:
mpierson:$ ./remove-transient-attrs.sh split-dir idm-key-prefix
... where split-dir is the name of the directory containing XML files to be cleansed, and idm-key-prefix is the first 5-6 characters of the instance ID prefix (i.e. '123456' in "#ID#123456789ABC...")
Note: here is the bash script that utilized find and perl to strip the relevant attributes.
Repeat for Reference Deployment
Repeat steps 1 thru 3 to produce an reference set of waveset objects. Ensure that you reference IdM deployment matches the version, including hotfixes, of the running instance being analyzed.
Catalog Differences in Custom Deployment
We applied diff recursively over the two sets of waveset objects:
mpierson:$ diff -N -r --brief -w reference-elements/ custom-elements/
The results of a diff will likely include a number of run-time objects, including User, Account, XmlData, and Syslog elements. Filter run-time objects from the diff for a better view of configuration:
mpierson:$ diff -N -r --brief -w reference-elements/ custom-elements/ |\
grep -v Account| grep -vi syslog |\
grep -v TaskInstance | grep -v "User-" |\
grep -v TaskResult | grep -v XmlData |\
grep -v WorkItem
We used a similar approach to produce a list of the XML objects that define the IdM configuration:
mpierson:$ diff -N -r --brief -w reference-elements/ custom-elements/ |\
grep -v Account| grep -vi syslog |\
grep -v TaskInstance | grep -v "User-" |\
grep -v TaskResult | grep -v XmlData |\
grep -v WorkItem |\
awk '{print $4;}' > files.txt
Notes: the results of this process provides a starting point for a rigorous reverse engineering endeavour. Manual inspection of the results, and extensive testing are recommended!
Posted in technology | Tags idm, sun | 1 comment | no trackbacks
