I have a issue with informatica environmental variables.
the variables are not getting displayed in unix.
[root#******]# su infadm
bash-4.2$ echo $PMEXTERNALPROCDIR
bash-4.2$
I check the variables session in admin console and all the path are defined correctly.
what could be the reason and what should i do if i have to see the value?
You probably started the integration service as a user other than infadm . Su to the user who starts the informatica service and check the variable value. If you don't know who started the services you could create a command task in workflow manager to run following command
whoami | cat > /home/youruser/whoisrunninginformatica
Just make sure you open the permissions on your home directory before executing it. If you dont care who is running the service you could use same strategy to cat the variable value itself.
I strongly recommend to use a specific user for Informatica Services, something like "ipcuser".
Change/login with that user and create the Informatica home folder, also change the ownership to the that user.
Once created, let's assume that you are using bash. Search and/or create the file .bash_profile
Edit all the variables in that file and work with the variables like this:
PATH=${PATH}:~/bin
export PATH
Once you edit use source .bash_profile and/or logout and login again.
Review the variables with env | grep PATH
Related
So I am trying to use trac as standalone bugtracker. I've generated user and password using script on this page. digest.txt file is in ~/.foo-trac/conf/ directory. Source looks like this:
montreal:FOO:904fa5b01944434358e48467fbf5203c
Running this command:
tracd -p 8000 --auth="foof,.foo-trac/conf/digest.txt,FOO" ~/.foo-trac/
Getting no errors but still not able to login. Strange detail is that tracd shows this line when I'm clicking log in:
127.0.0.1 - - [16/Oct/2014 03:47:53] "GET /.foo-trac/login HTTP/1.1" 500 -
What's going on?
UPD
Now I am trying to make it another way: using base auth on this page.
I've created new environment by this command: trac-admin /home/montreal/.trac initenv. In prompt I've given name Foo to my new project.
Then I've created new user by running this command: sudo htpasswd -c /home/montreal/.trac/.htpasswd username and entered a password. My .htpasswd file looks like this:
username:$apr1$bLbNsCx/$vbVXn5gn6HG.hJvvq/SaD1
Now I'm runnig trac by this command and getting the same result:
tracd -p 8000 --basic-auth="Foo,/home/montreal/.trac/.htpasswd," /home/montreal/.trac
Link says that first argument of --basic-auth should be projectdirname, but in /home/montreal/.trac no Foo directory.
It looks like I've got correct /fullpath/environmentname/.htpasswd argument.
But how can I get the realmname argument? Maybe it makes all the trick. Maybe some logs of tracd can be helpful but log folder is empty and I don't know another place to look.
I need this bloody bug-tracker.
Don't use relative paths (~/.foo-trac/) but absolute ones.
Same applies for the auth file path, that is not even relative like the path to your Trac environment but certainly wrong, because its absolute path is not /.foo-trac/conf/digest.txt, but this is what tracd is picking up from command-line as you see in the "strange" log line.
Enable Trac DEBUG logging in .foo-trac|.trac/conf/trac.ini as advised in the wiki documentation on this topic.
First argument of --basic-auth should be projectdirname, that is /home/montreal/.trac itself, commonly referred to as Trac environment directory, nothing else.
Please note that this is an AIX related question.
I have a jenkins server running on Redhat which is running a node via SSH on an AIX server.
The commands are run non-interactively using SSH to a user on the AIX machine who has ksh as its standard shell.
The problem is that this build needs a number of environment variables, and i can't seem to get it to work.
I have tried:
Jenkins allows me to set some environment variables for the session. So i tried:
ENV="$HOME/.profile"
I tried creating a .kshrc file containing
. .profile
But none of these approaches seems to make KSH run the .profile script.
The .profile script contains the environment setup for the user i need.
How do i get an AIX implementation of KSH to run my .profile script before executing commands?
You need to specifically tell Jenkins that you want to execute them in ksh shell.
By default, Jenkins runs as sh <commands>.
Add a shebang in your shell command as first line,
#!/bin/ksh
Most shells don't source their .profile files on non-interactive sessions. A simple solution is to source the .profile yourself as part of the command you are sending.
So instead of
yourcommand1; yourcommand2
you should send
. ~/.profile; yourcommand1; yourcommand2
over ssh
UPDATE after reading the comment about Jenkins controlling the ssh command
In the case your ssh command is performed by Jenkins you should have a look at https://wiki.jenkins-ci.org/display/JENKINS/SSH+Slaves+plugin, especially the 'Login profile files' paragraph.
I'd say one of these solutions is best
Set all environment variables from Jenkins using the node's configure page. Install the EnvInject plugin to do this.
Write a wrapper around the java command on the slave that sources your profile script and adjust the JavaPath (also on the node's configure page) to point to that wrapper.
The only way I know of for setting environment variables that will apply for non-interactive shells on AIX is via /etc/environment. I believe this is the correct place, but it will of course then apply to all users and all shells.
I have a Jenkins user that I want to give rights to run the remote CLI towards the Jenkins instance. The first command is to fetch the config.xml:
java -jar jenkins-cli.jar -s http://jenkins:8080/hudson get-job thejob
However when he invokes the command, it fails with:
Caught: java.lang.RuntimeException: \
hudson.security.AccessDeniedException2: \
USER is missing the Job/ExtendedRead permission \
at hudson.security.ACL.checkPermission(ACL.java:54)
I have given the rights to execute scripts, read/create/configure jobs and more in our matrix-based security grid. There is another user who has EXACTLY the same permissions in the grid, but for this other user, everything works fine.
I don't have any of the plugins 'Extended Read permission' or 'Read-only configurations' installed.
I cannot see why it fails for this new user. Suggestions anyone?
Differences in the 2 users config.xml file:
<com.cloudbees.plugins.credentials.UserCredentialsProvider_-UserCredentialsProperty plugin="credentials#1.4">
<credentials/>
vs:
<com.cloudbees.plugins.credentials.UserCredentialsProvider_-UserCredentialsProperty plugin="credentials#1.8.3">
<domainCredentialsMap class="hudson.util.CopyOnWriteMap$Hash"/>
And a final one:
<hudson.security.HudsonPrivateSecurityRealm_-Details>
<passwordHash>some values...</passwordHash>
</hudson.security.HudsonPrivateSecurityRealm_-Details>
I don't know if you are facing the same problem I had, but take a look here:
Jenkins CLI: using Anonymous permissions instead of the user defined ones
It looks like you have upgraded the credentials plugin but somehow the first user didn't get its record updated.
If you can I would suggest trying to update to the latest (1.9.1 for me). You could also edit the user record manually and force the real plugin version number in there (then restart Jenkins) and see if it processes this user more accurately.
I deploy some .bteq and .sql scripts on a TERADATA database. For doing this, I use a client on my desktop called BTEQWin version 13.10.0.03.
I get the .bteq/.sql from a version control like pvcs/svn etc and all I do once the files are in my workspace folder (from Version control tool), to just drag and drop the files from Windows browser to BTEQWin client (which I connect to a database prior to drag/drop for running those scripts).
Now, I have to automate this whole process in UNIX.
I have written a SHELL KSH/BASH script which is getting all the .bteq/.sql from a TAG/LABEL in the version control tool to a given UNIX folder. Now, all I need to do is the pass these files one by one (i'll take care of the order) to Teradata client.
My ?
- what client do I need to tell Unix admin team to install on Unix server - so that I can run something like below:
someTeraDataCommand -u username -p password -h hostname -d database -f filenametoexectue | tee output_filename.log
Where, someTeraDataCommand is the client / executable - which will let me run Teradata scripts (like I was doing using BTEQWin on my desktop - GUI session). Other parameters can be username, password, which database to connect on what server and which file to run or make that file passed to the command using "<" operator at command line.
Any idea?
- What client ?
Assuming the complete Teradata Tools and Utilities package is installed on your UNIX server (which will have the connectivity tools to talk to Teradata), you should have access to bteq from the command line. Something like this:
bteq < script_file > output_file
Your script file should contain a .LOGON statement to establish the connection:
.LOGON yourTDPID/your_account,your_pw
You might also need to use other commands to set your default database or non-default session values.
Another option would be to combine the SQL and call to BTEQ in a Korn shell script:
#!/usr/bin/ksh
##############
SHELL_NAME=`basename $0`
PRG_NAME=`basename $(SHELL_NAME} .ksh`
LOG_FILE=${PRG_NAME}.log
OUT_FILE=${PRG_NAME}.out
#
bteq <<EOBTQ > ${LOG_FILE} 2>$1
.LOGON {TDPID}/{USERID},{PWD};
--.RUN file=${LOGON}
/* Add your SQL/BTEQ commands here */
.QUIT 0;
EOBTQ
Edit
The double hyphen indicates a single line comment. Typically in a UNIX script you do not leave your password in plain text of a KSH script. The .RUN command would reference a text file in a barely sufficient secure location containing the .LOGON {TPDID}/{USERID},{PWD}; command.
The .RUN command in BTEQ allows you to reference another text file containing a series of valid BTEQ commands that you want to run in the current BTEQ script.
Easiest way is to setup the Solaris TTU, is to request root sudo, and run an interactive installation into defaults as a root. That would cure all client issues.
I have set up a php file to run that just echos hello.
<?php
echo hello;
?>
My cron job looks like this:
/usr/local/bin/php -f “/home/username/public_html/mls/test.php”
when my script runs i get a confirmation email that says:
Could not open input file: /home/username/public_html/mls/test.php
I don't know what is causing this. I am using godaddy's virtual private server with cpanel x installed. I have used the ssh to set permissions 777 on folder and file and still can not get it to run.
Any advice would be helpful. Thanks.
For some reason PHP cannot open the file. Try replacing /usr/local/bin/php -f with "ls -la" to try to crib some more information. Remember to NOT quote the file name in the crontab: php -f filename.php, not php -f "filename.php", unless it contains spaces -- and then it's better to use single quotes.
Possibly, try "ls -la /home", "ls -la /home/username", "ls -la ~/public_html" and so on.
Also try appending
2>&1
to the command line, in case only stdout is mailed to you (I don't really think so, but being sure costs little).
One other possibility
The crontab as it is refers /home/username/public_html/mls/test.php - that is, a public HTML directory inside username's commonest value for a home directory.
It is possible that the cron job is either not running with the appropriate user and privileges, or that the user it "sees" is actually a virtual user - there is no "/home/username" at all - and the "home directory" is elsewhere, possibly even existing just as long as the cron job runs. In this case the solution might be to refer to
~/public_html/mls/test.php
or, as described above, to first run a command such as pwd or ls -la to determine exactly where the cron job's current working directory is.
If this, too, fails, then another workaround could be to invoke the PHP HTTP handler via curl or lynx:
/usr/bin/curl http://www.thishostname.com/mls/test.php
Possibly using either some environment variable or curl header or _GET option to authenticate to the script as the cron job, and avoid it being accessible from the outside.