Tag Info

Hot answers tagged

5

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


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.


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 ...


3

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 # ...


3

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


2

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.


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

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

/usr/bin/env php looks for an executable named php in the current $PATH; it pays no attention to aliases, shell functions, etc. If you want it to execute php v5.3, you have to put that version in a directory under the name php, and put that directory in your PATH somewhere before the directory that contains version 4.4. Maybe something like this: mkdir ...


1

Set your $PATH so that the directory containing the version you want is listed first. and/or Change the first line in the script to point directly at the version of ruby you want: #!/usr/bin/ruby


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

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

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

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

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

"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.


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 ...



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