cherdeg
7th April 2008 14:23 UTC

Problems on Server 2008
Hello altogether,

we use NSIS to build an unattended installer for our customized CYGWIN package (see attached .nsi). This installer calls up "c:\cygwin\cygwin.bat" as penultimate step (last step is cleanup).

Background: When cygwin starts regularly (e.g. by executing bash via double-clicking the CYGWIN desktop icon) all shellscripts residing in "/etc/profile.d" are automatically executed. We use this functionality to execute a special script (copied to "/etc/profile.d" by the installer) to customize further options within cygwin.

From Windows 2000 to Windows 2003 R2 SP2 the installer works perfectly on all Windows OSses (even on x64).

Now Windows Server 2008 introduces a strange problem: if "cygwin.bat" (which starts "bash --login -i") is executed by NSIS (and only by NSIS...starting it manually works smoothly), bash is missing several environmental variables (reported by bash error message: "bash: cannot create temp file for here document: Bad address") and the scripts in "/etc/profile.d" won't be run.

I am not yet able to assign the source of this problem to either CYGWIN, Windows Server 2008 or Nullsoft Installer.

Personally I suppose that there is a problem supplying the standard environmental variables to "cygwin.bat".

Does anybody have a clue?

Best Regards,

Chris

Anders
7th April 2008 16:22 UTC

are you sure the working dir for the .bat is correct, currently its: SetOutPath "$INSTDIR\${DEST_SCRIPT}"

maybe it should be foo\cygwin or foo\cygwin\bin or something like that (Not sure why it would only break on 2k8 tho)

cherdeg
8th April 2008 07:49 UTC

Hi,

thank you very much for your reply. I'll try to set another SetOutPath (the one where the batch resides and /bin, where bash.exe is).

I'll report back asap.

Regards,

Chris

cherdeg
8th April 2008 08:17 UTC

Hi Anders,

I tried both ways described above: no changes unfortunately...

Regards,

Chris

Anders
8th April 2008 09:35 UTC

if you add a "set" line to the .bat, it should print all environmental variables, so you can compare with/without nsis. Also, Filemon/Procmon (http://technet.microsoft.com/en-us/s.../bb896645.aspx) might be able to give you some clues to why it can't find whatever its looking for...

cherdeg
16th April 2008 12:53 UTC

[SOLVED]
Hello AllofYou,

thank you very much for the efforts you took on to help me solve our problem. Finally we managed not to solve the problem itself but at least to find a workaround. Still we are not able to identifiy the one of the tree possible parties responsible for the problem: Nullsoft, Microsoft or Cygwin?

However: If, which I am sure of, anybody else in this world uses the Nullsoft-Installer to deploy an unattended Cygwin-Installation to his/her/its client machines, the person will, at latest when it comes to package-compatibility with VistaSP1 or Windows Server 2008, experience the same problem as we did. So I would like to document my workaround here:

When Cygwin's "setup.exe" is finished, it has installed a script "/etc/profile". Among others, one of the duties of this script is to find and run all scripts residing in "/etc/profile.d". This definitley does not work on VistaSP1 or Windows Server 2008...no matter who's to blame...bash reports the error: "bash: cannot create temp file for here document: Bad address" and none of the scripts in "/etc/profile" is run. The code in "/etc/profile" responsible for this is:

# Run all of the profile.d scripts
# Note that these are supplied by separate packages
# Ascending alphanumerical order enforced
if [ -d "/etc/profile.d" ]; then
while read f; do
if [ -f "${f}" ]; then
. "${f}"
fi
done <<- EOF
`/bin/find -L /etc/profile.d -type f -iname '*.sh' -or -iname '*.zsh' | LC_ALL=C sort`
EOF
fi

We decided to workaround the problem (we don't need to run all scripts in "/etc/profile.d" - in our customized configuration there never will be more than three...the code of "00bash.sh" and "openssl.sh" was directly) by hardcoding them to a customized "/etc/profile":

# Code from "00bash.sh"
/bin/test \! /bin/sh.exe -ot /bin/bash.exe
if ( $status ) then
/bin/bash.exe -c '. /etc/profile.d/00bash.sh'
fi
# Code from "openssl.sh"
export MANPATH="${MANPATH}:/usr/ssl/man"
# Run our script
if [ -e /etc/profile.d/ibm_customize_cygwin.sh ]; then
/etc/profile.d/./ibm_customize_cygwin.sh
fi;

This may not be elegant but at least works as planned. When Cygwin's "setup.exe" has finished, the Nullsoft-Installer copies and overwrites the original "/etc/profile" with our customized version which is then run every time Cygwin is started by "cygwin.bat".

Now we have another problem (regarding uninstall on W2K8), please refer to my new post in this forum.

Regards,

Christoph

cherdeg
16th April 2008 13:13 UTC

[wrong thread]

Ahhh...btw., what I forgot to mention: On XP the uninstall works as planned.

kichik
16th April 2008 23:15 UTC

Sounds to me like cygwin's installer is creating its environment variables only for the user which executed it. In Vista's case, with UAC turned on, that'd be the administrator and not the actual user.

cherdeg
21st April 2008 09:46 UTC

Hi kichik...

thanks for your reply...the machines we have here exist solely for software testing purposes (DB2, WebSphere, AIX). If any software is installed (inclunding the relevant NSIS package) it is definitely done by the local Administrator account on the system.

Question now would be: In Windows Server 2008 and VistaSP1: Even if the logged on user is localSystem\Administrator, is there a difference between the user starting the setup (the logged on account) and the user really copying the files (e.g. a machine account of some type)?

I also asked this question on the cygwin mailing list, but nobody was able to answer clearly...probably they simply don't know.

Regards,

Chris

kichik
21st April 2008 21:57 UTC

That's exactly the purpose of UAC - to create that segregation between the logged on account and the user running the setup itself. If the UAC dialog shows, your setup will run in a different context.

Anders
21st April 2008 22:09 UTC

Originally posted by cherdeg
Question now would be: In Windows Server 2008 and VistaSP1: Even if the logged on user is localSystem\Administrator, is there a difference between the user starting the setup (the logged on account) and the user really copying the files (e.g. a machine account of some type)?

UAC::GetElevationType
Parameters: <none>
Returns: $0
TOKEN_ELEVATION_TYPE:
0 Unsupported/Failed (ErrorFlag is also set)
1 TokenElevationTypeDefault: User is not using a split token (UAC disabled or not admin)
2 TokenElevationTypeFull: UAC enabled, the (current) process is elevated
3 TokenElevationTypeLimited: UAC enabled, the process is not elevated

cherdeg
22nd April 2008 09:32 UTC

Okay kichik and Anders, many thanks for your replies. BTW, at the moment we're only talking about Windows Server2008, we yet did no Vista tests. I have to re-ask my question to clarify:

If the user starting the software installation is localMachine\Administrator, UAC doesn't pop up. In this case, does the whole installation process run on the same elevation level using the same, unmodified token?

Does it matter if, e.g. as in our case, the Installer starts another executable (ExecWait setup.exe), which again calls runs certain core components (of cygwin) which again run several post-installation scripts. Later in the process the Installer starts a batch, which again starts another executable, bash.exe wich once again starts a script on the cygwin level that but accesses environmental variables defined on OS level?

Do all these manyfold processes run in the same (elevated) context of localMachine\Administrator? Or does Windows degrade the level of elevation in the 2nd or 3rd child process level?

I very much hope to have expressed my question understandable - the English classes in school are some years past meanwhile...

kichik
22nd April 2008 10:35 UTC

Check the output of following command to make sure.

nsExec::ExecToLog "cmd /c set"

mehdi79
22nd April 2008 15:24 UTC

just a suggestion
execwait has an error code return
verify this error code return