# Mar 18, 2012 - Unable to write inside TEMP environment variable path

I stumbled upon this beautiful error when trying to re-install my PostgreSQL 9.1.3 server: Unable to write inside TEMP environment variable path.

After some research and trial-and-terror [sic], I came to the conclusion that the essence of the problem had been a tiny change I made to my system's file associations (via Notepad++).

Here's how I solved it and how you can do it too:

I first made some research in the existing community but the solutions I found did not apply to me (I provide some links at the end of the page to these solutions):
• I checked if it was related to the option "Use temporary folders per session" in the "Remote Desktop Session Host Configuration";
• I checked the status of "Windows Script Host Settings" (whost.exe);
• I completely skipped antivirus-related stuff as I don't have any antivirus.

So, to understand why this error was happening, I went to my TEMP folder and read the log from the PostgreSQL installer:

C:\Users\myuser\AppData\Local\Temp\bitrock_installer.log

Which mentioned an interesting detail:
• Input Error: There is no script engine for file extension ".vbs".
So, I picked up another file from the TEMP folder, the actual script used by the installer:

C:\Users\myuser\AppData\Local\Temp\prerun_checks.vbs

And tried to run it through the console using cscript:

Input Error: There is no script engine for file extension ".vbs".

The same!
I researched a bit more and discovered that the type of file associated with the vbs extension had been changed. In my case, by Notepad++. After I installed Notepad++, I associated some file extensions with it (including vbs), thus causing problems when detecting the type of the script (which shouldn't happen).

Fixing it

Run the almighty regedit, navigate to HKEY_CLASSES_ROOT\.vbs and change the (Default) key back to the string VBSFile. In my case it had been previously altered to Notepad++_file.

 How the registry entries looked like before

 How the registry entries look when fixed

Then, restart PostgreSQL's installer and everything should go fine.

This is just a possible pair of cause-solution. Other solutions can be reached via some of the links below, don't forget to check them if my post doesn't apply to your issue.

Input Error: There is no script engine for file extension “.vbs”.
Running VBScript and JScript files from the Command Shell
Temporary directory environment variable in Windows Server 2008
Running & Installing PostgreSQL On Native Windows
Collect the installer log file (PostgreSQL)
Unable to write inside TEMP environment path

# Mar 16, 2012 - Running GlassFish as a service on Windows (Error 1067)

I've been trying to run GlassFish as a service on Windows:

asadmin.bat create-service

Unfortunately, that task didn't show up easy due to one little detail: GlassFish was installed on the famous Program Files folder. Other causes may just need a restart of Windows.

When starting the service, it says: Error 1067: The process terminated unexpectedly. And it really terminates.

Because there is a space character between Program and Files, the path to GlassFish also has spaces. The way GlassFish is called when requested via the service start makes it impossible to resolve the path correctly if there are spaces and other special characters, on Windows.

First of all, make sure you restarted your Windows after installing GlassFish as a service. I also had this problem when not using spaces in the path. After restarting the system, everything got fixed by itself.

Update: The following content, in a gray font, is composed of some workarounds for solving this problem. These workarounds are not required anymore because Byron Nevins just found out the right fix for this problem. Skip to the Solution.

I will not present the perfect solution, but some possible workarounds for this, although I encourage you to share your experiences below in the comments:

1.Just move your whole GlassFish installation to a directory with no spaces behind. It'll just work, no issues.

2.If you really want GlassFish to live in your old directory, you can create a symbolic link to that directory and put it in a legal path.
mklink /d C:\glassfish-3.1.2 C:\"Program Files"\glassfish-3.1.2
Now, create the service using the usual method and still at the old path:
asadmin.bat create-service
And edit the file C:\Program Files\glassfish-3.1.2\glassfish\domains\domain1\bin\domain1Service.xml (assuming base path is C:\Program Files):

• Remove every occurrence of: Program Files\\ or Program Files/, thus making the service executable point to your new symbolic link.

3.Create a service by hand, using sc (don't forget the space before the equal signs):

sc create MyGlassFishServiceName binPath= "C:\Program Files\glassfish-3.1.2\bin\asadmin.bat start-domain domain1" start= auto
This will create a service based on the usual GlassFish administration script, asadmin, so it's not a clean way and some errors may be thrown when manually starting the service. Also, it cannot be stopped. If you just want GlassFish to run as a service at startup, then this probably fits you enough. Update: Thanks to the fellow follower Micael Capitão that pointed out some typos in my command.

The Perfect Way.By editing the file I mentioned above, domain1Service.xml, we should be able to escape the spaces from from the path (usual escaping doesn't seem to work). Also, that could come as default in future versions of the splendid Oracle GlassFish (and the open source edition too, for that matter). Oracle already knows of the problem, like one of the following links reveals. If anybody knows/discovers how this can be achieved, please post in the comments below.

Solution
• After creating the service, edit the file:
C:\Program Files\glassfish-3.1.2\glassfish\domains\domain1\bin\domain1Service.xml
(assuming glassfish is installed at C:\Program Files\glassfish-3.1.2)

• Find the line:
<startargument>C:\\Program Files\\glassfish-3.1.2\\glassfish\\domains</startargument>

• Add double quotes around the path, like this:
<startargument>"C:\\Program Files\\glassfish-3.1.2\\glassfish\\domains"</startargument>

• Do the same for the line:
<stopargument>C:\\app\\big glass\\glassfish\\glassfish\\domains</stopargument>

How do I run GlassFish as a Windows service? (Oracle)
How to create a Windows service by using Sc.exe (Microsoft)

# Mar 15, 2012 - Change Jenkins or Hudson HTTP port number

One of the things server administrators of Jenkins or Hudson CI solutions often want to do, is to change the HTTP administration port.

I'll show you how, in 4 different ways: For Windows (service), WAR file deployed in GlassFish, Natively in linux and finally, using wrapper.

It's pretty simple:

For Windows (service installation)
Edit jenkins.xml or hudson.xml
Where is the jenkins.xml or hudson.xml?

Navigate to the directory where you installed Jenkins/Hudson and you will see the XML at the root. Open it and look for tag, there will be all the command arguments to be used when starting up Jenkins or Hudson.

One of those arguments is --httpPort, typically:
--httpPort=8080.
Change 8080 to whatever port number you want.

WAR File, deployed in GlassFish
You will need to change the default HTTP port in GlassFish.

Natively installed in linux
At least for RHEL, you should be able to find the /etc/sysconfig/hudson, which typically has the following line, among other configuration ones:
HUDSON_PORT="8080".
Change 8080 to whatever port number you want.

Other linux distributions (using wrapper)
At the time of writing, Arch Linux's AUR Jenkins version uses wrapper to launch itself from the .war file.

Edit /opt/jenkins/conf/wrapper.conf, find wrapper.app.parameter.2=--httpPort=8070 (typically).
Change 8070 to whatever port number you want.

This wrapper solution applies to any system using wrapper, not only linux.