Tag Info

Hot answers tagged

5

It's not env; it's the kernel's #! handler. Everything after the first word (/usr/bin/env) is passed as a single argument string. Safest/most portable is to not put anything after the perl there.


5

Use "/etc/sysconfig/httpd" to set Apache environment.


4

Split the unique sections into separate files, then use Include directives in the main http.conf to include other config files. You could for example wrap those Includes in IfDefine sections and then use the -D command-line startup option to define variables to turn on or off different sections of the config: <IfDefine DEVELOPER> Include ...


4

SetEnv is a directive for mod_env, and mod_env doesn't support %{ENV:var} -- only mod_rewrite does this. Don't forget that apache is modular, and modules define their own directives. You can do this with mod_rewrite like this: RewriteRule .* - [E=PROJECT_BASE:%{ENV:DOC_ROOT}] ... etc I must ask, what are you really trying to do? There must be a ...


2

If these are variables which apply to each and every user on the system, then they should be added in /etc/enviornment - but IIRC this file is not explicitly parsed by the init scripts. So you'd need to add a line in /etc/rc.d/init.d/functions, e.g. # -*-Shell-script-*- # # functions This file contains functions to be used by most or all # ...


2

I am assuming everyone is sharing the same user on the git server, and they each have their own key to log in with. If that is the case, then instead of identifying the remote user, you could easily identify the public key that the user used to log into the git server. To do that, you should allow PermitUserEnvironment in your server's sshd_config, and then ...


2

You can set the exempt_group option to tell sudo to keep the PATH for users in that group. For example, say your user is in the group 'sys'. Add the following to your sudoers file Defaults exempt_group="sys" Now your user will not have PATH reset for sudo commands (-E is not needed for this to work). See the man page for more details. EDIT: Going to ...


2

Do something like this watch bash -i -c 'alias -p' this should call bash, load your settings and then run whatever command you have after the -c


1

When you login with ssh user@serverB then manually execute the script it will prompt you for the passphrase the first time, then when you execute the script shh-agent will provide the stored passphrase. However when you run ssh user@serverB "sudo -E /path/to/script.sh you are doing a new login each time, and I don't think ssh-agent would support saving the ...


1

You must set it with RewriteRule. Try this: RewriteRule .* - [E=MY_URL_WWW:http://myURLtowhatever.com] PS: you can enable the mod_rewrite log with RewriteLog and RewriteLogLevel to see what happen.


1

Usually it's /etc/profile (readed by bash, dash, ksh, and its "sh" modes). For system users, you can declare single variables, at /etc/environment. It's not a good practice but it works (I used to use it for JAVA_HOME etc). The main issue with PATH is that it should be different for system users and for system superusers. So instead of a single variable in ...


1

Another possibility, if you control both hosts: good old identd. You can query identd on the originating host to see who set up the connection. This of course only works if you have full control over that host, or else you might get bogus data.


1

No, that information is not available in any way unless your git server can access the originating host as well (via ssh or something). In that case you can use netstat on both servers to match up ports, something like this in the hook: shost=$(echo $SSH_CONNECTION | cut -f1 -d' ') sport=$(echo $SSH_CONNECTION | cut -f2 -d' ') remotepid=$(ssh ...


1

Some cron daemons (e.g. Vixie cron on Debian/Ubuntu) allows the exact same syntax you wrote in your example. On other systems (RHEL etc.), use something like this in your crontab: * * * * * export COMPANYCRON=1; someperl.pl


1

Proposing another solution in addition to the one I already entered. This works for bash only (but can be modified for other shells). The following is a wrapper around sudo that will look for the command youre passing to it. Once it finds the command it changes it to the fully qualified path. So in effect sudo echo hello becomes sudo /bin/echo hello. Put ...


1

"Historic"? That's a new one. Here's an excerpt from the GNU coreutils 7.6 env(1) man page: -i, --ignore-environment start with an empty environment .... A mere - implies -i. If no COMMAND, print the resulting environment. Pass no command and see if there's a change in $PATH.



Only top voted, non community-wiki answers of a minimum length are eligible