I'm setting up an Amazon Web Service Stack and I'd like to configure the Document Root in /etc/apache2/sites-enabled/000-default.conf which I currently do by modifying the document's DocumentRoot. I then reflect this change in /etc/apache2/apache2.conf. Is it possible to make these changes with command lines as opposed to opening and editing files? Thanks in advance.
You can do it with sed. I use following wrapper function, to make it more convenient:
replace_string () {
while :; do
case $1 in
file=?*) local file=${1#*=} ;;
replace=?*) local replace=${1#*=} ;;
with=?*) local with=${1#*=} ;;
*) break ;;
esac
shift
done
sudo sed -i -- "s/$replace/$with/ig" $file
}
replace_string file='/etc/apache2/sites-enabled/000-default.conf' \
replace='.*DocumentRoot.*' \
with='DocumentRoot path-to-your-document-root'
replace_string file='/etc/apache2/apache2.conf' \
replace='.*DocumentRoot.*' \
with='DocumentRoot "path-to-your-document-root"'
Mind that user running this script should be capable of using sudo without a password.
If you have httpd.conf file
I don't know if this is supported by the documentation or not (I couldn't see reference to it) but I found that appending will replace previous directives.
I stumbled upon this experimentally after becoming disillusioned with the cocophony of sed, grep and awk scripts that usually accompany this kind of question (see Modify config file using bash script).
In my case, I have a file called httpd_changes.conf which looks like this:
DocumentRoot "/my/new/web/dir"
<Directory "/my/new/web/dir">
Options Indexes FollowSymLinks
AllowOverride None
Require all granted
</Directory>
Then when I set up the webserver (in my case it's in my Dockerfile) I run this prior to starting the httpd service:
cat httpd_changes.conf >> /etc/apache2/httpd.conf
If you don't have a httpd.conf file
This isn't my situation but as far as I can tell you can just put a new config file in your conf.d directory. Those files are read in alphabetically (according to this page https://superuser.com/questions/705297/in-what-order-does-apache-load-conf-files-and-which-ones) which is obviously much nicer than my hack.
You could try the following:
sed "s,/var/www/html,/my/new/web/dir,g" /etc/apache2/sites-enabled/000-default.conf
This will display the modification that would be made on your file.
The , is used as a custom delimiter to make the regex easier to read.
This example with replace all occurences of /var/www/html with /my/new/web/dir.
Add the -i flag to actually modify the file:
sed -i "s,/var/www/html,/my/new/web/dir,g" /etc/apache2/sites-enabled/000-default.conf
Related
I am trying to run a script via apache on a shared linux server, like
#!/usr/bin/perl
print "Content-type: text/html\n\n";
foreach $i (keys %ENV) {
print "$i $ENV{$i}\n";
}
But I want to run it via. a symlink created like this
ln -s printenv.pl linkedprintenv.pl
It runs fine directly but I got a 500 server error when executing via the symlink from a web browser. I understand the solution may be to create a .htaccess file containing
Options +FollowSymLinks
but I tried and that didn't work. Is there extra configuration needed for that single line htaccess file to take effect?
In my ~/.ssh/config I added the following:
Include /Path/to/ssh.config
And it gives error:
ssh remoteEc-2
/Users/Me/.ssh/config: line 1: Bad configuration option: include
/Users/Me/.ssh/config: terminating, 1 bad configuration options
ssh -V gives:
OpenSSH_6.9p1, LibreSSL 2.1.8
I am on OSX El-Capitan
Include is not a valid option until version 7.3...
See: https://www.openssh.com/txt/release-7.3
New Features
[...]
ssh(1): Add an Include directive for ssh_config(5) files.
Also, see this answer.
If you can't / don't want to update, then you could collate your configuration files, using the following:
cat ${CONFIG_1} ${CONFIG_2} ${CONFIG_3} > ~/.ssh/config
You'd need to run it every time you update any of the parts...
Same problem, except I'm on 7.4
Turns out, the Include directive needs to go into /etc/ssh/ssh_config, not /etc/ssh/sshd_config (note the d in the filename).
Wasn't obvious to me. Hope this saves whoever finds this some time.
My httpd.conf file contains following configurations
SSLPassPhraseDialog builtin
#SSLPassPhraseDialog exec:/root/passphrase.sh
when the line containing automatic reading of Passphrase is commented it works fine.
But when i change it to
#SSLPassPhraseDialog builtin
SSLPassPhraseDialog exec:/root/passphrase.sh
it fails, just with a failed message.
contents of passphrase file
#!/bin/bash
echo "xyz123"
Check rights permissions of passphrase file.
Possible causes for this.
Some times users put the passphrase-script under /etc/httpd/conf.d
directory. Don't do that.
Some time that script need to have execute (chmod +x) permission.
May be /bin/bash doesn't work with the current Linux distro then you have to include /bin/sh.
I've narrowed down this question - regarding a MySQL over SSH connection only working once - to a conflicting line in my host computer's known_hosts file.
Essentially, I can not get into my Database GUI of choice because the key is different for the same IP address (after re-provisioning, reloading, etc.).
Once I delete any offending lines, I can get in just fine.
So, through Vagrant's shell command (that I'm provisioning with) how can I modify the host machine's ~/.ssh/known_hosts file?
EDIT:
I found a temp fix that involves adding/creating a ~/.ssh/config file (this involves using a private IP address):
Host 192.168.*.*
StrictHostKeyChecking no
UserKnownHostsFile /dev/null
Should let you in. Not a real fix, as this kind of fix can be a security concern. Look below for much better answer.
Sorry for taking you away from what you need!
Changing HOST files from Vagrantfile:
What you actually want is very simple. Vagrantfile is interpreted by Vagrant each time you run vagrant command. It is regular ruby code, so if you want to change HOST file, all you need to do is to put in the Vagrantfile Ruby code that performs this change. Here's the example code I've put at the end of my Vagrantfile:
require 'tempfile'
require 'fileutils'
path = '~/.ssh/known_hosts'
temp_file = Tempfile.new('foo')
begin
File.open(path, 'r') do |file|
file.each_line do |line|
if line !~ /REGEX_OF_LINE_YOU_WANT_TO_EXCLUDE/ then
temp_file.puts line
end
end
end
temp_file.rewind
FileUtils.mv(temp_file.path, path)
ensure
temp_file.close
temp_file.unlink
end
Note to edit the code above by putting your own value for REGEX_OF_LINE_YOU_WANT_TO_EXCLUDE.
Hope I at least partially fixed my mistake by providing this answer :)
Original Answer
For anyone's (mine as well) future reference, I'm leaving part of the answer that refers to changing GUEST OS files or copying files to GUEST OS:
Vagrant provides couple of provisioners.
Solution number 1: For simple file copy you may use Vagrant file provisioner. Following code in your Vagrantfile would copy the file ~/known_hosts.template from your host system to VM's file /home/vagrant/.ssh/known_hosts
# Context -------------------------------------------------------
Vagrant.configure('2') do |config|
# ...
# This is the section to add ----------------------------------
config.vm.provision :file do |file|
file.source = '~/known_hosts.template'
file.destination = '/home/vagrant/.ssh/known_hosts'
end
#--------------------------------------------------------------
end
File provisioner is poorly documented on Vagrant site, and we've got to thank #tmatilai who had answered similar question on serverfault.
Keep in mind that you should use absolute paths in destination field, and that copying is being performed by vagrant user, so file will have vagrant's owner:group.
Solution number 2: If you need to copy file with a root privileges, or really have to change the file without using templates, consider using well documented shell provisioner. File copying in this case would work only if you have the file placed in the folder visible from within the VM(guestOS), but you have all the power of shell.
Solution number 3: Though it would be overkill in this case, you might use very powerful Chef or Puppet as provisioners, and perform action via one of those frameworks. I know nothing about Puppet, and may talk only about Chef. Cookbook would be very simple. Create template file (.erb) with desired content, and then your recipe will just place the file where necessary. Of course you'll need a box with Chef packeges in it.
I use plain ssh to enter my machines in order to do provisioning:
$ ssh-add ~/.vagrant.d/insecure_private_key
With this setup the known hosts is bound to give problems, but I do not want to turn off the host key checking as I use that also for external hosts. Given my hosts include pattern foo, I did this on the shell:
$ ssh -i '' '/foo/d' ~/.ssh/known_hosts
Remove the empty '' argument after -i if you have GNU/linux host in stead of BSD/MacOSX.
You can then install the vagrant trigger plugin:
$ vagrant plugin install vagrant-triggers
And add the above snippet to the Vagrantfile (mind the backticks):
config.trigger.after :destroy do
puts "Removing known host entries"
`sed -i '' '/foo/d' ~/.ssh/known_hosts`
end
This is what I do:
I define the IP_ADDRESS and DOMAIN_NAME variables at the top of the Vagrantfile.
Then inside Vagrant.configure I add:
config.trigger.after :destroy do |trigger|
trigger.info = "Removing known_hosts entries"
trigger.run = {inline: "ssh-keygen -R #{IP_ADDRESS}"}
trigger.run = {inline: "ssh-keygen -R #{DOMAIN_NAME}"}
end
I've been advised to remove the return command from my bashrc file in order to allow Ruby Version Manager to function properly. Do I simply delete the return command, or do I replace it with some other command? I am hesitant to mess with my System-wide shell without some proper direction. But I would really like to get RVM working as it is a time saver.
My bashrc is located in the etc directory and looks like this:
# System-wide .bashrc file for interactive bash(1) shells.
if [ -z "$PS1" ]; then
return
fi
PS1='\h:\W \u\$ '
# Make bash check its window size after a process completes
shopt -s checkwinsize
if [[ -s /Users/justinz/.rvm/scripts/rvm ]] ; then source /Users/justinz/.rvm/scripts/rvm ; fi
The last line, is an insert, described in the RVM installation.
I wouldn't. That return is probably there for a good reason. It obviously doesn't want to execute anything after that if the PS1 variable is empty.
I would just move the inserted line up above the if statement.
In addition, if that's actually in the system-wide bashrc file, you should be using something like:
${HOME}/.rvm/scripts/rvm
rather than:
/Users/justinz/.rvm/scripts/rvm
I'm sure Bob and Alice don't want to run your startup script.
If it's actually your bashrc file (in /Users/justinz), you can ignore that last snippet above.
The last line uses a file in a specific user's home directory, and as such should not be in the system-wide bashrc, since only root and that user will have access to that file. Best to place it in that user's ~/.bashrc instead.