IZPack Setting Linux Environment Variables - linux

I am sure this has to be out there somewhere, but after about a day of searching I am stuck. I am trying to use IZPack to do an installation on Linux and trying to call a shell script that sets some environment variables. However I don't know how to "source" the script instead of just running it. Running the script using:
<executable type="bin" stage="postinstall" targetfile="$INSTALL_PATH/myscript.sh" os="unix"/>
This only executes the script, it does not source it. So all exports of ENV variables are lost once the script completes.
How can I source my scripts from IZPack instead of just running them?

IMHO you simply cannot influence the shell environment your Java process of your IzPack installer is running in from that process itself.

Torsten is right. This is not an issue of IzPack, Java or anything else, this is just the way operating system process work with respect to environment variables ;-)

Related

Environment for rc.local

I need to create an environment variable that is set within a bash script. I want this environment variable to be a system wide environment variable and I also want to be able to use it in an if condition in rc.local. So far I have tried /etc/profile but rc.local does not see it when I set it there.
Which script should I set this environment variable in so that rc.local can see it when I boot?
Other question while I’m at it. Who starts rc.local?
Cheers,
Dave
Rc.local runs before the operating system is fully booted but has not yet started the login shell, so the environment variables we configured in /etc/profiles or bashrc are not executed, so no environment variables are visible during the rc.local implementation phase.
The solution is:
Add export ENVNAME=*********** before the command in rc.local

Start script on linux startup

I try to execute a java application at startup in a yocto based linux device. I added a script at /etc/init.d/etic and made it executable. If I call at the shell /etc/init.d/etic start or /etc/init.d/etic stop the application is started an stopped as expected. Then I called on the shell update-rc.d etic defaults and the symlinks were created. According to what I found on the web, this should be enough, but somehow the application is not started. What did I miss? How could I check what is going wrong or is there any minimal example which should work which I can try to extend?
Well, often such issues are due to a different environment when executing the start script by hand, as compared to when it's being run from the init system. For instance, your .profile and .bashrc won't have been sourced, when running from the init system.
You can use eg logger to easily log things from your init-script, and this rather easily find out what goes wrong.

changes in shell script does not refresh in Linux

I have a shell script, called startmq.sh, to run activeMQ. However I changed the script, it did not refresh the changes at all.
Even I only wrote echo "Hello World", it did not refresh and was trying to run activeMQ with wrong parameters.
Then, I copy startmq.sh to abc.sh and tried to run abc.sh. It showed Hello World.
Plus, I need to use that standard name startmq.sh.
Thanks.
can it be, that you have this script multiple on the server?
under bash do the following whereis shows you the locations of the script(s) and which shows you witch script ist starting ...
bash:# whereis startmq.sh
bash:# which startmq.sh
There must be another copy of startmq.sh somewhere accessible due to its path being amongst the PATH enviroment variable.

Environment Variable not being passed to CruiseControl, specifically the 'nodosfilewarnings' ENV variable from Cygwin

I have a Perl program that someone else created and I am calling on with CruiseControl. The program calls on Unix Commands using Cygwin. However, everytime that the Perl program calls on a Unix like command with a DOS like address, I get the well known error:
cygwin warning:
MS-DOS style path detected: E:\regression
Preferred POSIX equivalent is: /cygdrive/e/regression
CYGWIN environment variable option "nodosfilewarning" turns off this warning.
Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
I have set both the User Variable AND System Variable CYGWIN to nodosfilewarning. This removes the error when I run the program from the command line, but the error still occurs in CruiseControl when called as an automated process from a batch file. I have called on both the batch file from the Desktop AND Command Line and ran as an administrator. Nothing changes.
Other Notes
For purposes of this problem, I don't have access to the Perl Program
I am trying to go back to Cygwin 1.5.*, but since I am using Server 2008, I am encountering compatibility issues
This is occurring on one of the distributed servers, not the main server running the Webdashboard.
I have read somewhere that this issue may stem from a different user calling on CruiseControl, but the issue should have been solved by setting this as an ENV System variable
Is it possible to modify the registery to set the ENV variables?
Thank you in advance
The way I do it is like this
printf 'export CYGWIN=nodosfilewarning' >> ~/.bash_profile
If CruiseControl is connecting to the server via ssh, reinstall sshd and explicitly include nodosfilewarning when prompted for the CYGWIN environment variable during the install.
Re-installing with modified environment will work but if you don't want to or cannot re-install, an alternative is to change the registry instead of re-installing the service.
See: CYGWIN windows cygrunsrv sshd server and MS-DOS style path detected

On OpenSuSE (or linux in general) where should a non-service startup script go?

On an OpenSuSE linux machine, I want to run a script when the machine is booted. As the script does not start a service, is /etc/rc.d the correct place for the script?
Thanks.
That's where I've always put them. There are several scripts in rc.d already which don't actually start a process. However, you need to write it in a similar fashion to the other startup scripts - have a look at a few to see how they are set up. Specifically, you should make sure that it's possible to run the script using /etc/rc.d/myscript start.

Resources