I've got a Django project which works great. Previously we just cloned down and used password authentication. I changed the remote to git#bitbucket.org:myteam/our_repo.git
Recently we started requiring 2FA, so now we can only clone down over SSH.
For this project, I created an access key (read-only, which is all I need for cloning down on a staging server) and I was able to clone down the repo (git clone git#bitbucket.org:myteam/our_repo.git) without issue and get it all set up. This appeared to have worked.
The other server admin remoted in and tried to run git pull origin master, he got a permission issue. His windows user is part of the Administrators group - but for some reason that didn't matter. His local user had to be added to the directory with full access before he could run git pull origin master
It appears that this permission issue is causing other issues, too. File uploads (from the Django admin) are no longer actually uploading the files into the directory on the server - my guess is that this is related to the permissions issue, too. Nothing was changed to impact this - the project was just cloned down over SSH.
Does cloning something down over SSH change the permissions on the directories or somehow lock it down more? This wasn't an issue before - only since we've switched over to SSH.
Any feedback is helpful!
Does cloning something down over SSH change the permissions on the directories or somehow lock it down more?
No, it does not change anything locally.
And 2FA is only impacting HTTPS URL (where your password must be a PAT, Persoanl Access Token)
It has no bearing on SSH URLS.
Check first ssh -Tv git#github.com output.
Related
I wanted to ask something regarding Debian Virtual Machine on Google Cloud. So I've set some configurations on my Compute Engine and on my laptop such that I can ssh to the VM from my laptop with ssh account1#IPAddress and now I'm logged in as account1#VM-name $ in my terminal. After doing so, I clone my own GitHub Repo to start my Node.js server (the Node.js server might be unimportant in this case, but the git clone is important to the story line). Then, I decided to disconnect from terminal and decided to do SSH-in-browser method. With that I'm logged in with my email, that is let's say account2#VM-name $. However, when I typed ls, the GitHub folder is not there. Is this normal with Debian VMs across cloud services such that different accounts cannot see other folders, or is there actually away to share the same files with different "ssh accounts"? Or maybe I should sudo git clone such that it is saved in the root folder in the VM?
Thanks a lot for the help!
when you logged using account1#vm-name and cloned your github repo it will be available in /home/account1 directory.
Now when you are logged in now with account2#vm and do ls , it will show details of /home/account2 and it is obvious nothing is there.
you can use below commands.
sudo cd /home/account1
ls
I am running django server, using gunicorn. Apart from gunicorn, I have a layer of nginx as a load balancer and using supervisord to manage gunicorn.
From the perspective of security is it fine to run my gunicorn server with sudo permission? Is there any potential security leak?
Also, does it makes any difference if I am a superuser and not running process with sudo permission as in any case I have sudo permissions as the user.
Does it need to run as root?
If it doesn't, don't run it as root.
Even better, add a separate user for the app and run it as that user.
I believe the answer to question "is it ok to run xxx with root permissions" should not be "If it doesn't, don't run it as root." but rather a clear "NO".
Every single server and framework is designed to be run without root rights.
What can go wrong? In case you have a vulnerability allowing to remotely execute code on the server you would be simply giving root rights to whoever can exploit it. In case one of your developers in team does something stupid like deleting the root directory, it will be deleted. You don't want that a single app running on the server disrupts your whole system, do you?
It is not a good practice to run any external network facing application with root user privilege.
Consider a scenario where your uploaded file is not validated or sanitized ( file upload vulnerability). If someone uploads some vulnerable file and executes it. Consider that file to have implemented reverse shell. Then it gets easier to take down your server.
I'm working with a website running on laravel. The site works fine on my local through Homestead, no problems.
Recently, I pushed the git repo up to a server that never had this site running on it before. I set everything up right (had some nginx config issues for a while, but got those all sorted out). Nginx has the public folder set as the site root, so it hits the proper index page when you load the page.
What I'm getting is a 500 error. My error logs reveal the following is the reason:
site_root/public/../bootstrap/autoload.php - Failed to open stream: permission denied
in
site_root/public/index.php on line 22
I can confirm that the bootstrap folder and the autoload.php file are both accessible by the web user, and have permissions that should allow access.
I've read a few cases online of people solving this issue with a 'composer install'. I tried updating composer, doing an install, and dumping its cache. I also tried removing the vendor folder (which had been a part of the git repo), and running composer install to regenerate it. None of these have worked. Happy to supply any info that will help. This is Laravel 5.2 running on Ubuntu Server 14.04 with nginx, all on an AWS box.
Solved it. This was actually an issue with site-wide permissions. They were set to 770 instead of 775. I suspect that I can and should restrict them more. For now, I'm just happy to have it loading again.
Moral of the story is to check your permissions site-wide, not necessarily just on the file which gives you the fatal error. You may continue to get the same fatal error, despite permissions being wide-open on the mentioned file. If so, look for permissions issues elsewhere.
I am trying to deploy a webapp to Azure. I am following these directions https://azure.microsoft.com/en-us/documentation/articles/web-sites-python-create-deploy-django-app/
First step, I created a webapp (Django) on the portal.
Then it says to follow the directions to configure Continuous deployment using GIT in Azure App Service. This should apparently lead to my having a local directory of Django files. https://azure.microsoft.com/en-us/documentation/articles/web-sites-publish-source-control/
So I follow those directions, installing Git, creating a local repository, adding a webpage, enabling web app repository, deploying.
The webportal now shows that I have deployed ('active' deployment). However, when I go to the web app url, what's showing is NOT what I deployed, but rather what I guess is the default Django app with its urls (login, logout, contacts).
So then I create an actual Django app in my local directory (instead of the static index.html from the directions). I commit and push it to Azure. It shows as being deployed.
The result is the same as before: the default web app is showing.
So what I'm missing is the connection between my local repository and what's actually showing. Is there some way to pull the Azure default app into my local repository? (Once it's there, I'll be able to change it as I see fit.)
Things are working as expected, but you ended up overwriting the Django app in your first the Git commit. The Continuous Deployment instructions as written are generic to any deployment, even a blank Web App.
So what I'm missing is the connection between my local repository and what's actually showing. Is there some way to pull the Azure default app into my local repository? (Once it's there, I'll be able to change it as I see fit.)
All you need to do is git clone your repo after you've initialized your local Git repo on the Azure Web App. You've already gone through most of these steps, but I'll include them here for others who may be looking for this answer.
After you create the Django Web App from the Azure Marketplace/Gallery, scroll down to set up continuous deployment.
Choose Local Git repo.
Notice that you now have a Git Clone URL in both your Quickstart Essentials info and under All Settings >> Properties. Go ahead and copy this URL.
If you haven't already done so, you may need to set or reset your Deployment Credentials. You'll find this under All Settings. This will be your Git & FTP credentials. Note that this is actually the credentials for your Microsoft Account, not just this one Web App.
You already have Git installed from your first attempt. You should now be able to navigate to the folder you want to clone the repo into and run:
git clone <your_git_clone_url>
After you type in your password, you'll have a cloned repo of the Django Web App on your local system. cd into the directory and start working from there. Once you have changes, git add ., git commit, and git push them back to the repo in Azure to see your changes there.
I have a Django application and am using AWS servers to host the app. Before, I used to do
git add .
git commit -m 'made changes'
git aws.push
and it used to work perfectly fine. All of a sudden, I did it again after a few weeks and now it says
Error: Failed to get the Amazon S3 bucket name
. When I do
eb status
it says
routines: SSL3_GET_SERVER_CERTIFICATE: certificate verify failed
Why is it giving me these errors when it used to work perfectly fine a few weeks ago? I never changed my IAM user's password. Does it change automatically? Because I still have the credentials file when I created the IAM user and the password in that file is the same password I am using.
Is there any error log where I can get further information to debug this issue?
It's a trite answer, but I'd suggest updating eb. They've made some improvements to the API since I last updated earlier this week, and some changes to their architecture when it comes to Python apps (now defaulting to Python 3). Running pip install awsebcli --upgrade may do the trick, if Amazon have made potentially breaking changes, or the Boto library is out-of-date on your machine.