This is a short note about using GnuPG on Windows 7/2008R2 to encrypt file(s) with symmetric AES encryption. GnuPG is installed on every Linux box that I work with. Fortunately, Windows port is well maintained and for simple batch use it’s enough to install Gpg4win-vanilla package from gpg4win.org. Current version Gpg4win 2.2.21 is shipping GnuPG 2.0.22.
Make sure that you have Gpg4win binaries in PATH (try to run gpg2), if they’re not then add to your path:
SET PATH=C:\Program Files (x86)\GNU\GnuPG;%PATH%
Here is an example of encrypting single file with gpg2:
cmd> gpg2 --batch --yes --passphrase mysecret -z 0 --cipher-algo AES128 --output "D:\TEMP\MYBACKUP.BAK.gpg" --symmetric "D:\ETL\MYBACKUP.BAK"
We’re telling gpg2 that we’re running command in batch mode (–batch), that we don’t want to compress data since input file is already compressed (-z 0) and that we wan’t to use AES128 encryption. With –output switch we’re telling gpg where to write encrypted file – this parameter always precedes command (–symmetric in this case), otherwise we get an error. In current version it’s not possible to specify wildcards for files, so encrypting single file is the only option with –symmetric command.
Decryption is as easy as:
cmd> gpg2 --batch --yes --passphrase mysecret --output "D:\ETL\MYBACKUP.BAK" --decrypt "D:\TEMP\MYBACKUP.BAK.gpg"
Yesterday migration of our main OLAP server from MS Analysis’s Services 2005 to 2008 R2 was (more or less) uneventful experience, we thought installing “SQL Server Business Intelligence Development Studio” on developers desktops running Windows 7 x64 would be as dull as migration itself. That was not the case. It took us almost half a day troubleshooting error that prevented us to open any Cubes in our migrated databases from developer workstation. Every attempt was greeted with the error “Insufficient memory to continue the execution of the program”.
Configuration of the workstation looks like this:
- Windows 7 Enterprise (x64)
- Oracle client 11gR2 (32-bit)
- MS Office 2010 (32-bit)
- MS SQL Server BI Studio 2008 R2 (32-bit)
- HW: Fujitsu Esprimo Workstation with iCore5 and 8GB of RAM
Everything patched to the maximum possible level as of May-21-2013. My first assumption was that something related to x64 vs. x86 miss-match between installed components is preventing VS shell to open the cube, but how if all components that need to work together are 100% 32-bit!?
After I dismissed my initial hunch and some other miss-trials, I did what every self respecting systems engineer does in such situation. I went to seek some intimacy in my “cubicle”, then when no one was looking I opened the Chrome and asked Google for help. Typical day in the life of SE, don’t you think?
At last I found a post from Jerry Nee in this thread, pointing to Microsoft Download Center where we can download “Office 2003 Add-in: Office Web Components” needed by MS BI Studio 2008R2 to browse the cubes. After I installed owc11.exe on developer’s workstation browsing cubes was at last possible.
Many thanks to Chief Software Architects at Microsoft. Keep up with your work, as long as you’re doing your job as you do, I’m not worried to loose mine.
I was struggling for quite some time with my colleague at work on migration of our legacy (ODAC 10g + .NET 2.0) client/server applications to centrally managed runtime environment. Applications that run flawlessly by the users with Windows XP SP3, stopped working on newer configurations with Windows 7 x64 and ODAC 11g R5.
This is a short memo on how to prepare runtime environment for Oracle ODAC based .NET application that can be run from a network drive. Oracle at the time of this writing does NOT have a proper document covering a “true” XCOPY based installation. With a “true” XCOPY installation I mean the one that doesn’t need any super user privilege to install application on client — we want totally GAC agnostic ODP.NET application runtime env. In short, we don’t want to run neither install.bat nor configure.bat script from ODAC client zip file shipped by Oracle.
(If you wonder why? Because GAC is utterly disgusting .NET “thing”, almost as disgusting as the windows registry, and a clear evidence that MS will never learn from *nix).
In summary the objective is:
- allow our end users with Windows XP SP3 (32-bit) or Windows 7 EE (32-bit or 64-bit) to run simple WinForms .NET applications in C/S mode
- some clients are also developers with local (“by-the-book”) installation of ODAC (10g, 11g) with GAC registrations, they should be able to run prod. applications in a complete isolation from their local environment.
- all .NET application must be installed centrally on our main file server and must as well use centrally installed Oracle client with ODAC
- all that is needed to install application on client workstation is to create shortcut that points to startup routine to launch application from file server. No super-user privilege is allowed as a prerequisite for application installation!
And here are the steps that we followed:
- Download “ODAC 11.2 Release 5 (22.214.171.124.20) with Xcopy Deployment” from OTN”
- Unzip ODAC1120320Xcopy_32bit.zip to some temporary directory, let’s say G:\TEMP. Then copy relevant directories (in our case instant client + ODP.NET 4.0) to network drive.
Do NOT run install.bat! Let’s say that our target network directory that’ll be used by all .NET apps is N:\ORACLE\ORA11odacR5.
// copy instant client and odp.net4 from temp directory
// to network based N:\ORACLE\ORA11odacR5
cmd> cd g:\temp
cmd> xcopy instantclient_11_2 N:\ORACLE\ora11odacR5 /I /E /F /R /Y
cmd> xcopy odp.net4 N:\ORACLE\ora11odacR5 /I /E /F /R /Y
- make sure that .NET application build is targeted at .NET 4.0 and x86 platform. We do NOT recommend using “Any CPU” for mix (32-bit & 64-bit) clients, sometimes we run into problems on x64. We also strongly recommend using 4.0 for the lowest .NET target framework. Previously (.NET 2.0 – 3.5) we needed to authorize client PC’s before users could run .NET apps from our file server. On .NET 4.0 this is not necessary any more. Since 4.0 is the highest .NET framework version still supported on XP SP3 the decision to deploy to 4.0 was trivial. Some screenshots showing our build instructions:
Note that on second picture application “build” is using locally installed Oracle.DataAccess.dll (framed in blue) and this is ok. Developers can use whatever Oracle.DataAccess.dll they want, even an older one (one of our application was developed with 10g Oracle.DataAccess.dll, but deployed to runtime env. with ODAC11g R5), because in the next step we’ll override developer “choice” with our network based (latest) ODAC 11g R5. And this can be done with app. config.
- Generate and then customize application config xml file (in our case OraDUAL.exe.config. And precisely here is where Oracle documentation is not clear and precise enough. How should application config look like that could be used on workstation without any Oracle client (more precisely on workstation where Oracle OUI or install.bat didn’t run, hence machine.config is untouched).
<?xml version="1.0" encoding="utf-8" ?> <configuration> <!-- configSections was copied here from one of our developer's machine.config where ODAC11g R5 was installed with install.bat. Note that you can not blindly copy this section because different ODAC version may have different PublicKeyToken. Always check what Oracle sets up! --> <configSections> <section name="oracle.dataaccess.client" type="System.Data.Common.DbProviderConfigurationHandler, System.Data, Version=126.96.36.199, Culture=neutral, PublicKeyToken=b77a5c561934e089" /> <section name="system.data.oracleclient" type="System.Data.Common.DbProviderConfigurationHandler, System.Data, Version=188.8.131.52, Culture=neutral, PublicKeyToken=b77a5c561934e089" /> </configSections> <!-- This section needs either properly edited machine.config from Oracle OUI (or install.bat from instant client) or manually added configSections (see above). Note that DllPath needs to point to the Instant client directory, not to the Oracle.DataAccess.dll directory! --> <oracle.dataaccess.client> <settings> <add name="DllPath" value="N:\ORACLE\ORA11odacR5"/> <add name="FetchSize" value="65536"/> <add name="PromotableTransaction" value="promotable"/> <add name="StatementCacheSize" value="0"/> <add name="TraceFileName" value="%TEMP%\odpnet.trc"/> <add name="TraceLevel" value="0"/> <add name="TraceOption" value="0"/> </settings> </oracle.dataaccess.client> <!-- Here we're telling .NET framework two things: - which version of Oracle.DataAccess.dll we want to be used - and from where exactly it should load the assembly. Any version of Oracle.DataAccess.dll between 0.0.0.0 and 184.108.40.206 will be replaced by 220.127.116.11. Note that publicKeyToken is "hash" dedicated to Oracle Corp. but might change in the future. We checked the token against GAC. --> <runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <publisherPolicy apply="no" /> <assemblyIdentity name="Oracle.DataAccess" publicKeyToken="89B483F429C47342" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-18.104.22.168" newVersion="22.214.171.124"/> <codeBase version="126.96.36.199" href="file:///N:\ORACLE\ORA11odacR5\odp.net4\odp.net\bin\4\Oracle.DataAccess.dll"/> </dependentAssembly> </assemblyBinding> </runtime> </configuration>
In case the application is build with additional libraries that internally depends on Oracle data provider (Oracle.DataAccess.dll) the same kind of config file needs to be prepared for each library (for example if OraDUAL.exe needs OraAcme.dll and OraAcme.dll is referencing Oracle.DataAccess.dll, then OraAcme.dll.config must be present with redirecting directives already shown in app.config).
- The final step is to prepare batch routine to launch our application from network drive.
:: RunOraDUAL.bat :: Oracle11g [188.8.131.52] Instant Client with ODAC 184.108.40.206.20 :: :: Batch routine to launch OraDUAL.exe from newtork drive. :: :: --------------------------------------------------------- title Oracle11g Instant Client - ODAC 220.127.116.11.20 SET NLS_LANG=SLOVENIAN_SLOVENIA.EE8MSWIN1250 SET NLS_DATE_FORMAT=DD.MM.YYYY SET ORACLE_HOME=N:\ORACLE\ORA11ODACR5 SET TNS_ADMIN=N:\ORACLE\ORA11ODACR5 SET PATH=%ORACLE_HOME%;%ORACLE_HOME%\ODP.NET4\BIN;%ORACLE_HOME%\odp.net4\odp.net\bin\4;%PATH%; start OraDUAL.exe :: End
Make sure that you include both \BIN directories that belongs to ODP.NET4 to the path!
In our case we put RunOraDUAL.bat in the same directory with OraDUAL.exe and OraDUAL.exe.config.
Note that you do NOT need to place Oracle.DataAccess.dll to application directory even though VisualStudio will copy
Oracle.DataAccess.dll in \BUILD directory because we instructed this with “Copy Local = True” (refer to screenshot #2)!
The only thing we copied to network share N:\APPS\OraDual is exe and config file.
I have a plenty of Windows interactive batch files that are using choice.com tool as a helper when I need some input from the user, for example:
:: *********** :: * BEGIN * :: *********** :begin color 0e cls echo. echo ********************************************** echo You started interactive batch script.... echo ********************************************** echo Select server: echo (1) EUROPE echo (2) ASIA echo (3) US echo (4) ALL THREE echo (5) EXIT echo. ..\util\choice /C:12345 Pick one if errorlevel 5 goto end if errorlevel 4 goto all if errorlevel 3 goto US if errorlevel 2 goto ASIA if errorlevel 1 goto EUROPE :EUROPE ... do some stuff ... goto end :ASIA ... do some stuff ... goto end :US ... do some stuff ... goto end :ALL ... do some stuff ... goto end :: END :END
Choice.com is 16-bit application that can not run on Windows x64. The simplest workaround that I found is to use SET /P command. It’s a little bit of more code to write, but it’s quite trivial and does not hurt script readability. We can rewrite above script as:
:: *********** :: * BEGIN * :: *********** :begin color 0e cls echo. echo ********************************************** echo You started interactive batch script.... echo ********************************************** echo Select server: echo (1) EUROPE echo (2) ASIA echo (3) US echo (4) ALL THREE echo (5) EXIT echo. set choice= set /P choice="Select 1..5: " :: :: I used ~0,1 to "substring" first character from the input :: if not '%choice%'=='' set choice=%choice:~0,1% if /I '%choice%'=='1' goto europe if /I '%choice%'=='2' goto asia if /I '%choice%'=='3' goto all if /I '%choice%'=='5' goto end :: :: if we came here then we know that user entered :: echo "%choice%" is not a valid option pause echo. goto begin :EUROPE ... do some stuff ... goto end :ASIA ... do some stuff ... goto end :US ... do some stuff ... goto end :ALL ... do some stuff ... goto end :: END :END
For many years I run a particular python script as a service on my Windows XP machine. I used Microsoft Resource Kit tool srvany to “host” my script as as service. Recently, I replaced my XP machine at workplace with new one, running Windows 7 x64. Unfortunately, Microsoft stopped developing this tool, I heard that it still works, even on Windows 7 x64, but nevertheless I consider srvany as being dead.
Fortunately, there is good alternative, NSSM – Non Sucking Service Manager, free replacement for srvany with a bonus – it’s build for both, 32-bit and 64-bit OS.
Download and simply unzip nssm archive, then open elevated command prompt and install the service with the command nssm install , in my case:
cmd> nssm install PyLogDirWatch