As I found a blocker in one approach to make a Django app production ready I've gone with a different approach documented here.
In particular, this question is about this step where it says «Restart Apache for the changes to be taken into effect» and has the following associated command
sudo /opt/bitnami/ctlscript.sh restart apache
Thing is, ctlscript.sh isn't in that folder but in /opt/bitnami/stack. Then, when running in that forder
sudo ctlscript.sh restart apache
I get this error
sudo: ctlscript.sh: command not found
The file is there so I thought it would be something related with permissions (as pointed here).
The script is in the right folder, so the problem points to incorrect permissions.
sudo chmod 755 ctlscript.sh
but running the command to restart Apache got me into the same "command not found" error.
"command not found" does not point to "incorrect permissions". You're getting errors because the script is not in your PATH. There's two ways you can go this
Discover and specify the full path.
Specify the current directory.
Method 1
Run
pwd
and you will get the full path. If you get /home/bitnami/stack, then, run
sudo /home/bitnami/stack/ctlscript.sh restart apache
Method 2
Run
sudo ./ctlscript.sh restart apache
and that will work too
The following worked for me (I was getting a command not found error too):
sudo /opt/bitnami/ctlscript.sh restart apache
Taken from https://docs.bitnami.com/aws/faq/administration/control-services/
Related
Haii everyone
How to start Odoo server automatically when system is ON.
Normally i searched in google i had found a link " http://www.serpentcs.com/serpentcs-odoo-auto-startup-script-322 "
i follow the each and every step and i started the odoo-server
ps -ax | grep python
5202 ? Sl 0:01 python /home/tejaswini/Odoo_workspace/workspace_8/odoo8/openerp-server --config /etc/odoo-server.conf --logfile /var/log/odoo-server.log
it is showing the server path also
but when i run 0.0.0.0:8069/localhost:8069 in browser it is running
shows This site can’t be reached
please any one help me
Thanks in advance
To start a service automatically when the system turns on, you need to put that service into init script. Try below command
sudo update-rc.d <service_name> defaults
In your case,
sudo update-rc.d odoo-server defaults
Hope it will help you.
For the final step we need to install a script which will be used to start-up and shut down the server automatically and also run the application as the correct user. There is a script you can use in /opt/odoo/debian/init but this will need a few small modifications to work with the system installed the way I have described above. here is the link
Similar to the configuration file, you need to either copy it or paste the contents of this script to a file in /etc/init.d/ and call it odoo-server. Once it is in the right place you will need to make it executable and owned by root:
sudo chmod 755 /etc/init.d/odoo-server
sudo chown root: /etc/init.d/odoo-server
In the configuration file there’s an entry for the server’s log file. We need to create that directory first so that the server has somewhere to log to and also we must make it writeable by the openerp user:
sudo mkdir /var/log/odoo
sudo chown odoo:root /var/log/odoo
reference
I have a standard Debian 8.9 instance on google cloud compute (GCE) where my startup script is ignored.
In the custom metadata field, for startup-script, I am trying to run an Rscript (which is used for batch execution of R files), followed by a system shutdown, with the following:
#! /bin/bash
sudo /usr/bin/Rscript /home/myuser/launch_script.R
sudo shutdown -h now
Starting the instance is immediately followed by a shutdown and the Rscript is ignored. Removing the last line to shutdown causes the GCE instance to start, but the Rscript to be ignored. Running just "sudo /usr/bin/Rscript /home/myuser/launch_script.R" from the terminal results in the script being run. It has a chmod of 755, so I don't think this is a permissions issue.
In addition to this problem, I have read elsewhere that logging should happen in /var/log/, but there is nothing there. Instead, I have a bunch of log files (that only contain the start-up script and nothing else) in the root of my instance:
I got in touch with Google cloud support, who gave the following response:
script definition is kept under /var/run/google.startup.script
If the script does not run initially, you can force it manually with : $ sudo google_metadata_script_runner --script-type startup # for Debian, or # sudo /usr/share/google/run-startup-scripts # on Ubuntu and older images
I'm posting this information here, because it is not in their documentation (as of August 2017). I'm not sure how helpful it is, since the google.startup.script didn't exist in my case (using the latest Debian image on GCE), but I did run the other commands.
However, I think my main issues were:
I was using autossh to connect to a remote database. The startup-script was running before autossh. Building a 40 second delay into the script and running the script as a user (not sudo-type root) seems to have solved this problem for now. Autossh was being run as the main user, which I think gets loaded before lower-privilege user-defined scripts get loaded.
I was using some gcloud commands from the user account which had its own authentication issues. Running gcloud auth login as the user and ensuring correct permissions on my private key solved this.
Always remember to check the messages and syslog files in /var/log for troubleshooting. This allowed me to see the order of things being loaded at system-boot.
I have installed Redmine and I've been playing around with a few themes. I am having trouble installing a custom logo. I add the new file in the correct folder and reference it in the correct stylesheet but when I inspect it in the browser it says "Failed to load the given URL"
I also tried making changes to the base.html.erb file and this did not show up either.
Simple changes to the stylesheet do work however.
Thanks for your help :)
Man, doing anything with Redmine customization is not easy but I finally got it. I followed this tutorial, http://www.redmine.org/projects/redmine/wiki/Howto_add_a_logo_to_your_Redmine_banner
However this did not actually work on my system so I added a few commands of my own. If these commands do not work then try adding sudo in front of them. THis will prompt you for the admin password.
Near the end, the tut tells you to do this in command line:
chown redmine:redmine /opt/redmine/public/images/logo.png
Now I am using Apache so my path would look more like this
chown apache:apache /var/www/redmine/public/images/logo.png
Anyway I tried that and it still had no effect, now the additions I was doing was either under public/images or public/themes so I chose to just target the public folder. This may be bad practice when going live but I am only working locally on a virtual machine.
Here is what worked:
chown -R apache:apache /var/www/redmine/public
chmod -R 775 apache:apache /var/www/redmine/public
The -R stands for recursive so it effects the child files too. chmod 775 allows read, write, execute permission for Owner & Group, and only read, execute permissions for Other.
Restart your server after that (the command could be slightly different depending on your setup, refer to the tut)
/etc/init.d/httpd restart
This was very confusing for me at first so let me know if anyone needs more clarification on the subject. I am using Redmine installed on a CentOS virtual box.
I followed the directions outlined in AWS documentation for creating an Elastic Beanstalk application, however after deploying my application via "eb start" the status was red. I checked the log files and learned that my requirements.txt file had an error in it (I used "=" where I should have used "=="). I fixed by requirements file, checked it into Git, and did a "git aws.push". This did not get my app running and when the app auto updated it gave me the same error. I figured an "eb stop" "eb start" would do the trick (maybe a full manual restart would work?) but that didn't work either. I eventually had to delete my app and recreate it to get the old requirements.txt cleared out so that the new one could be used.
Is this expected behavior? I'm new to AWS Elastic Beanstalk and read through as much doc as I could however I couldn't find any footnotes describing behavior in a scenario like this.
Create a file like this:
# .ebexetensions/always-update-pip.config
container_commands:
keep-pip-up2date:
command: pip install -r requirements.txt
After you have run git aws.push and the environment has been updated, take a snapshot of your logs. In the /var/log/eb-tools.log You should see which pip requirements are being updated/installed and which requirements already exist.
My Django app is built on a VM Ubuntu instance via a Fabric script ran from my local dev machine as root with sudo. The Fabric script sets up a folder in:
/var/log/FOLDERNAME
and the app is set to log all log data into it.
However after each build even though the right permissions (group & folder) exist on the folder (ls -all confirms it) the log files have trouble getting generated unless I SSH to the box after each Fabric build and physically type in:
sudo chmod 777 /var/log/FOLDERNAME -Rf
... then everything works fine.
Can anyone please shed some light and/or point me in the right direction to solve this?
Cheers!
use put with mode to setup your logfile folder with permissions.
put('yourlogfile', 'yourlogfile', mode=0755)
A sidenote: Using chmod 777 is generally not a good idea. If your VM is running ubuntu your apache runs by default as www-data. chown www-data and r-w permissions for this user/group should be enough.